Moin, ich habe eine kurze Frage, die ich durch Suchen und Lesen im Datenblatt nicht beantworten konnte. Wie werden im AVR Befehle, die mehrere Takte dauern, zum Beispiel mul und sbiw ausgeführt? Läuft die Pipeline während der Berechnung weiter und der Multiplizierer arbeitet parallel oder wird sie für einen Takt angehalten? Gibt es einen Stall? Instinktiv habe ich, als ich noch Assembler programmiert habe, immer mul r16,r17 nop ; Warte auf Ergebnis mov r16,r0 mov r17,r1 geschrieben. Das nop könnte man natürlich auch durch eine andere Operation ersetzen. Bringt das was oder wird erst auf das Ergebnis gewartet und dann der nächste Befehl ausgeführt? Mir kommt es nicht auf die paar Takte an, ich würde nur gerne die Funktionsweise kennen. Im Datenblatt habe ich nur die Ausführung von '1-Takt-Befehlen' gefunden.
Die Takte aufeinander folgender Befehle darf man bei AVRs exakt so addieren, wie sie in der Doku stehen.
holger schrieb: > seit wann habe AVR's eine Pipeline ? Haben sie, aber eine sehr einfache 2stufige: fetch/execute.
Dussel schrieb: > Instinktiv habe ich, als ich noch Assembler programmiert habe, immer > mul r16,r17 > nop ; Warte auf Ergebnis Warum? Steht das so im Datenblatt? Im allgemeinen ist dem Datenblatt zu folgen, besser als jeder Instinkt. Ich wüßte keinen MC, wo das Ergebnis eines Befehls nicht für den direkt nachfolgenden Befehl gültig ist. Es gibt beim AVR Wartezeiten, z.B. beim Zugriff auf asynchrone Timer. Aber alle RAM oder Registerzugriffe sind direkt nach Befehlsende gültig.
holger schrieb: > seit wann habe AVR's eine Pipeline ? Seit 1996, wenn ich richtig informiert bin. Peter D. schrieb: > Warum? > Steht das so im Datenblatt? Nein. Ich habe damals, das ist ja auch schon ein paar Jahre her, gelesen, dass der Befehl zwei Takte braucht, also habe ich mir gedacht, dass im nächsten Takt=nächsten Befehl das Ergebnis noch nicht da sein kann. Das habe ich dann ohne drüber nachzudenken später immer so gemacht. Jetzt frage ich mich halt, ob nächster Takt=nächster Befehl richtig ist. Peter D. schrieb: > Ich wüßte keinen MC, wo das Ergebnis eines Befehls nicht für den direkt > nachfolgenden Befehl gültig ist. Ich kenne nur den AVR ganz gut. Sonst nur verschiedene Prozessoren mal kurz im Studium und Cortex irgendwas auf einem SoC, wobei der nur Beiwerk für die Kommunikation war. Peter D. schrieb: > Aber alle RAM oder Registerzugriffe sind direkt nach Befehlsende gültig. Das beantwortet dann meine Frage eindeutig, nachdem ich den Beitrag geschrieben habe. Danke
> Ich wüßte keinen MC, wo das Ergebnis eines Befehls nicht für den direkt > nachfolgenden Befehl gültig ist. Normalerweise kümmern sich moderne CPUs um solche stalls in der Pipeline selber jedoch wude MIPS minimalistisch gebaut um transistoren zu sparen. Also muß man sich selber (bzw. der Compiler) um stalls und Pipeline Hazards kümmern. Microprocessor without interlocked pipeline stages; deutsch etwa „Mikroprozessor ohne verschränkte Pipeline-Stufen" https://de.wikipedia.org/wiki/MIPS-Architektur
1 | mul r16,r17 |
2 | nop ; Warte auf Ergebnis |
3 | mov r16,r0 |
4 | mov r17,r1 |
Bitte lass das nop weg - es ist überflüssig. Auch bei allen anderen "Mehrtaktinstruktionen". (Auf was für Ideen man alles kommen kann...)
>..jedoch wude MIPS minimalistisch gebaut um transistoren zu sparen. ARM eigentlich auch >Also muß man sich selber (bzw. der Compiler) um stalls und Pipeline >Hazards kümmern. ja da ist MIPS die (schlechte) Ausnahme! (wenigstens hat ARM sowas nicht) Man muss bei manchen ASM-Befehlen tatsächlich aufpassen, ob das Ergebnis des vorigen Befehls überhaupt schon vorhanden ist (ggfs nop's einfügen). (sowas bei AVR würde (bei den Leuten der Fangemeinde) wohl niemand hinnehmen)
Dussel schrieb: > Instinktiv habe ich, als ich noch Assembler programmiert habe, immer > mul r16,r17 > nop ; Warte auf Ergebnis > mov r16,r0 > mov r17,r1 Also selbst wenn er mehrere Pipelines hätte wäre das nop in jedem Falle unsinnig, er würde dann auch ohne nop gezwungenermaßen warten. Sattdessen würde man auf so einem Prozessor in der Zeit lieber etwas anderes machen als Zeit mit einem vollkommen unsinnigen nop zu vertrödeln. Insofern ist unklar warum Du (oder irgendwer) "intuitiv" nops irgendwo hinschreiben würde.
Intel hatte mit dem i860 mal einen Prozessor, dessen Pipeline offen sichtbar war - wenn Tempo gefragt war - und dann vom Programmierer berücksichtigt werden musste. Ohne Interlocks. Die Programmierung war selbst für Compiler so spassbefreit, dass er bald wieder von der Bildfläche verschwand. https://en.wikipedia.org/wiki/Intel_i860#Performance_.28problems.29
Die SH Prozessoren von Renesas brauchen vielfach ein NOP hinter Befehlen wie BSR oder BRA, da vor der gewünschten Verzweigung schon der nächste Befehl ausgeführt wird. Glücklicherweise weiß der Compiler, wann dies notwendig ist und wann nicht.
Bernd K. schrieb: > Sattdessen würde man auf so einem Prozessor in der Zeit lieber etwas > anderes machen als Zeit mit einem vollkommen unsinnigen nop zu > vertrödeln. Lesen bildet: Dussel schrieb: > Das nop könnte man natürlich auch durch eine andere > Operation ersetzen. ;-) Manche AVR haben (zusätzliche) Timer, manche AVR haben USART, manche AVR haben ADC und manche AVR haben Hardwaremultiplizierer. Wegen dieser 'Analogie' habe ich mir den Multiplizierer immer als eine Art Peripheriemodul vorgestellt, das parallel zum Kern arbeitet, so dass der Kern/die Alu während der Multiplikation parallel noch etwas anderes machen kann.
> Intel hatte mit dem i860 mal einen Prozessor, dessen Pipeline offen
sichtbar war
Er ist nicht deswegen verschwunden. Er war schief im Markt. Zur gleichen
Zeit kam der 80386 raus. Am Intel Stand an der damalig angesagten Messe,
ca 1985, wurde ich gefragt was ich denn mit der gigantischen
Rechenleistung eines 386 wolle. Das war den Intelverkaeufern selbst
nicht so klar. PCB Proogramme waren damals noch nicht so gut wie heute.
Eigentlich gabe es keine. Worauf denn. Auch wenn diese wahnsinnig
schnelle 386 Cpu mit 33MHz lief, war nicht mal schnell an ein Design zu
denken. Einen Compiler gab es von Intel, zumindest auf dem Papier, zu
einem Mondpreis. Es war mir etwas unklar worauf der haette laufen
sollen. Ein Betriebssystem auf einem 386 gabs noch nicht. Nix Protected
mode, das kam alles nachher von Microsoft, als Win95, dabei hatte sich
das Win3.1 noch nicht mal so richtig etabliert. Das OS/2 von IBM kam
auch dann auch auf dem 386. IBM hatten leider eine falsche Politik, dh
nicht marktgerecht. Geschlossene Hardware, wie Apple damals auch schon,
zu Mondpreisen. Wir sind IBM, und daher sowieso gut. Nur waren die
damaligen IBM Kunden die Anwender von Grossrechnern, und die kleinen PCs
waren fuer einfache Leute, in kleinen Firmen. Auch wenn fuer eine OS/2
Maschine um die 10k abgedrueckt werden musste. Also der 386 kam grad
vorher raus.
Der i860 auch. Der i860 war eigentlich ein hochparalleler DSP, ohne DSP
interface. Dh man musste bei der Hardware alles zu Fuss machen. Der
konnte auf Audiofrequenzen unten ein digitales Filter mit 500.Ordnung in
Echtzeit rechnen. FFT, Matrizen, alles unwahrscheinlich schnell, mit
hochparallelen MAC (multiply-accumulate), er war angelehnt an die
Transputer, die waren damals auch draussen, oder angekuendigt.
Heutzutage wuerde man den i860 mit GPU bezeichnen. Auch hier. PCB
Programme gab's so eigentlich noch nicht. und der 860 lief glaub mit 60
oder so MHz. Compiler auch nur von Intel. Auch hier war nicht wirklich
klar, worauf der haette laufen sollen, auf einem DOS PC mit 640k eher
nicht. Der Compiler hatte natuerlich auch einen Mondpreis. Die wenigen
Firmen, die eine solche Entwicklung, dh i860 Hardware zum Markt bringen,
haetten stemmen koennen waren nicht dran interessiert. Denn das Geld
alleine genuegte nicht. Man musste auch die Leute haben. Die Leute,
die's haetten machen koennen, waren junge Absolventen. Die
Entscheidungstrager hatten vielleicht eine PDP 8, eine VAX auf der
Bestellliste, und waren damit zufrieden. Die ambitioesen Absolventen
gingen damals zu DEC, die bezahlten gut, waren ein technologisch
orientiertes Startup, im Vergleich zu IBM, welche Grossrechner fuer
Grossfirmen bauten.
Es ist immer noch unglaublich spannend, wie schnell und wieviel Momentun
die PCs entwickelten, und innert kuerzester Zeit die Grossrechner
ueberfluegelten.
ich selbst hab ein 8086 Sytem zusammengebaut bevor es den PC gab. Das
386 Datenblatt war noch ein Stueck umfangreicher, hab ich auch gelesen.
Das i860 Datenblatt hab ich auch gelesen. Beide, mangels Anwendung aber
nicht gebaut. ich hatte ja nicht mal eine Anwendung fuer das 8086er
system. Denn ohne OS, ohne Compiler wird's schwierig. Ich begann ein OS
zu schreiben, aber mit Hex Code eintippen kommt man nicht so schnell
vorwaerts. Als dann die PCs von urspruenglich 20k auf 4k runter kamen,
hab ich dann einen solchen gekauft.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.