Hallo, ich möchte abschätzen wie lange ich für gewisse mathematische Operationen auf einem 32-bit AVR UC3 brauchen werde. Der Quellcode steht noch nicht, nur die analytischen Formeln. Nun ist im Datenblatt (technical reference) nicht von "execution time" oder "clocks" die Rede sondern von issue latency. Das ist auch netterweise im Datenblatt definiert. Aber ich bin mir nicht sicher ob ich das richtig verstanden habe. Im Datenblatt steht: > Issue latency > The issue latency represents the number of clock cycles required between > the issue of the instruction and the issue of the following instruction. > For some change-of-flow instructions, this includes the cycle penalty > caused by the pipeline flush. The issue latency assumes, unless stated > otherwise, that the instruction and data memories are able to return an > instruction or data in a single cycle, which may not be true for slow > program memories or data memories mapped on the HSB bus. dabei ist eine "issue" definiert als: > An instruction is issued when it leaves the ID stage and enters the EX stage. Ist nun die "issue latency" die Zeit zwischen dem Erreichen der ID-Phase eines Befehls und dem Erreichen der ID-Phase des nächsten Befehls? Das sagt mir doch im Prinzip wenig über die Zeit aus, die ein Befehl komplett braucht, oder? Wie kann ich mir nun die Zeit ausrechnen die meine Berechnung wirklich braucht? Und zwar will ich nicht nur wissen, wann ich den nächsten Befehl in die Pipeline schieben kann, sondern auch wann ich das Ergbenis der Rechnung erhalte. Dank im Voraus, David
Bei Pipelining von Befehlen und Ausführungseinheiten gibt es zwei relevante Zeitparameter: - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung steht. - Wie lange dauert es, bis der nächste Befehl bzw. die nächste Operation gestartet werden kann. So kann ein partiell gepipelineter Multiplizierer beispielsweise 4 Takte benötigen, bis das Ergebnis feststeht, aber bereits nach 2 Takten die nächste Operation vertragen. Ein anderer vollständig gepipelineter Multiplizierer benötigt möglicherweise 5 Takte für das Ergebnis, akzeptiert aber in jedem Takt eine neue Operation. Welcher der beiden ist schneller? Je komplexer eine CPU ist, desto schwieriger ist es, die Laufzeit auf dem Papier auszurechnen. Irgendwann geht es nur noch mit praktischer Erprobung, manchmal auch mit leidlich exakter Simulation.
Hallo A. K., irgendwie hast Du mir nicht wirklich auf meine Frage geantwortet oder übersehe ich da was? A. K. schrieb: > - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung > steht. Genau das ist meine Frage. > > - Wie lange dauert es, bis der nächste Befehl bzw. die nächste Operation > gestartet werden kann. Das scheint ja die issue latency zu sein. > > So kann ein partiell gepipelineter Multiplizierer beispielsweise 4 Takte > benötigen, bis das Ergebnis feststeht, aber bereits nach 2 Takten die > nächste Operation vertragen. Ein anderer vollständig gepipelineter > Multiplizierer benötigt möglicherweise 5 Takte für das Ergebnis, > akzeptiert aber in jedem Takt eine neue Operation. Welcher der beiden > ist schneller? Das hängt ab wie viele Operationen ich ausführe. Bei n Operationen braucht man 4 + 2*(n-1) Takte (bei dem ersten Fall) bzw 5 + 1*(n-1) Takte beim anderen Fall. Dh bei nur einer Operation ist die erste Art der Multiplikation schneller. Sobald man mehr als 2 Operationen ausführen muss die ideal gepipelined werden können ist die zweite Art der Multiplikation schneller. Aber warum fragst Du das? Was ich eigentlich wissen wollte ist wo ich im Datenblatt zum AVR UC3 [1] die Information finde wie lange die jeweiligen Instruktionen brauchen bis sie mir das Ergebnis liefern (also der erste Punkt in Deiner Auflistung). A. K. schrieb: > PS: AVR im Betreff anführen, aber AVR32 meinen, ist wie links blinken > und rechts abiegen ;-). Ähm, ok. Ich dachte AVR32 wäre eine Teilmenge von AVR. Schließlich beschriebt die ATMEL diese Familien unter einen Titel: [2] Aber Du hast wohl Recht, da das ja ein anderer MP ist. Viele Grüße, David [1] http://atmel.com/dyn/resources/prod_documents/doc32002.pdf [2] http://atmel.com/products/avr/default.asp?family_id=607
David H. schrieb: > irgendwie hast Du mir nicht wirklich auf meine Frage geantwortet oder > übersehe ich da was? Ich hatte irgendwann mal in AVR32 reingesehen aber keine Details im Kopf. Ähnliche Begriffe und verschiedene Zeiten abhängig von der Betrachtungsweise sind mir jedoch aus anderem Kontext gut bekannt und daraus ergab sich dieser nicht unmittelbar auf AVR32 bezogene Beitrag. In der Hoffnung es nützt dir was. > Aber warum fragst Du das? Eigentlich war das eine rhetorische Frage ;-). Sollte andeuten, dass es keine einfache Antwort gibt. > Ähm, ok. Ich dachte AVR32 wäre eine Teilmenge von AVR. AVR und AVR32 haben den Hersteller gemeinsam. Sonst nichts.
A. K. schrieb: >> irgendwie hast Du mir nicht wirklich auf meine Frage geantwortet oder >> übersehe ich da was? > [...] dieser nicht unmittelbar auf AVR32 bezogene Beitrag. > In der Hoffnung es nützt dir was. Ja die Unterscheidung der Zeitparameter war mit bewusst. Trotzdem danke! :-) Wenn jemand genaueres weiß wäre ich für Details dankbar! > Was ich eigentlich wissen wollte ist wo ich im Datenblatt zum AVR UC3 > die Information finde wie lange die jeweiligen Instruktionen > brauchen bis sie mir das Ergebnis liefern. Grüße, David
David H. schrieb: >> - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung >> steht. > Genau das ist meine Frage. Da die execution units des AVR32 anscheinen nicht pipelined sind ist das noch vergleichsweise einfach und man kann die Takte plus eventuelle im Text erwähnte Zusatztakte offenbar direkt einsetzen. Es wird allerdings durch den "accumulator cache" etwas verkompliziert, so dass auf manche Operationen (MAC in allen Varianten) je nach Kontext ggf. ein Takt drauf kommt. > Das scheint ja die issue latency zu sein. Es scheint hier keinen Unterschied zwischen den beschriebenen Varianten zu geben. Wobei man schon sehr genau lesen muss, denn im Text sind einige "wenns" und "abers" vergraben. > Das hängt ab wie viele Operationen ich ausführe. Auch, aber nicht nur. Wenn die aufeinanderfolgenden Operationen voneinander abhängen, dann ist die 4er Version immer schneller. Das war's worauf ich rauswollte.
Hallo noch mal A. K., A. K. schrieb: > David H. schrieb: >>> - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung >>> steht. >> Genau das ist meine Frage. > Da die execution units des AVR32 anscheinen nicht pipelined sind ist das > noch vergleichsweise einfach und man kann die Takte plus eventuelle im > Text erwähnte Zusatztakte offenbar direkt einsetzen. Ja gut. Also im Datenblatt steht > This chapter presents the instructions in AVR32UC CPU, and the number of > clock cycle they require to complete. Da hätte ich erwartet, dass es eine tabellarische Übersicht gibt in der auch die execution cycles aufgelistet sind. Statt dessen steht diese Information verstreut im Kapitel "Instruction Cylce Summary" (einfach nach cycle suchen, nicht nach clock). Im letzten Unterkapitel "Code example" ist auch noch mal ein Beispiel mit den benötigten Ausführungszeiten aufgezeigt. Was ich aber nicht gefunden habe ist, wie lange die Befehle der FPU brauchen. Ich nehme mal an das wird dann die issue latency (+1?) sein. > durch den "accumulator cache" etwas verkompliziert, so dass auf manche > Operationen (MAC in allen Varianten) je nach Kontext ggf. ein Takt drauf > kommt. Du meinst, wenn es dann nicht im Cache ist und noch geladen werden muss, dass dann kommt noch mindestens ein Takt drauf kommt? >> Das scheint ja die issue latency zu sein. > Es scheint hier keinen Unterschied zwischen den beschriebenen Varianten > zu geben. Wobei man schon sehr genau lesen muss, denn im Text sind > einige "wenns" und "abers" vergraben. Meinst Du damit, dass also idR die execution cycles = issue latency? >> Das hängt ab wie viele Operationen ich ausführe. > Auch, aber nicht nur. Wenn die aufeinanderfolgenden Operationen > voneinander abhängen, dann ist die 4er Version immer schneller. Das > war's worauf ich rauswollte. Ja stimmt. Das sollte wirklich nicht vergessen werden. Bin jetzt schon weiter gekommen! Danke. Der Inhalt von den Datenblättern ist halt nicht trivial. Grüße, David
David H. schrieb: > Was ich aber nicht gefunden habe ist, wie lange die *Befehle der FPU* > brauchen. Ich nehme mal an das wird dann die issue latency (+1?) sein. Da die FPU ausdrücklich als "optional" angeführt ist: Bist du sicher dass dein Exemplar überhaupt eine drin hat? Mein Eindruck ist, dass dieses Kapitel ein Vorgriff auf die Zukunft ist.
David H. schrieb: > Meinst Du damit, dass also idR die execution cycles = issue latency? So sieht es beim AVR32UC aus. NB: Ich habe grad auf meiner Platte eine Techref vom AVR32AP gefunden, in der es durchaus einen Unterschied gibt. Aber dieser Core hat eine andere Pipeline.
Auf der Webseite finde ich keinen AVR32, bei dem eine FPU erwähnt wird. Ich denke nicht, das Atmel sowas verschweigen würde. Ich finde nur einiges Geschwurbel, das auf eine nicht näher dokumentierte zukünftige Version mit FPU vertröstet. Wenn du sowas brauchst, wär's vielleicht besser du suchst anderswo die Laufzeiten zusammen.
A. K. schrieb: > David H. schrieb: > >> Was ich aber nicht gefunden habe ist, wie lange die *Befehle der FPU* >> brauchen. Ich nehme mal an das wird dann die issue latency (+1?) sein. > > Da die FPU ausdrücklich als "optional" angeführt ist: Bist du sicher > dass dein Exemplar überhaupt eine drin hat? Mein Eindruck ist, dass > dieses Kapitel ein Vorgriff auf die Zukunft ist. Ich habe das Gerät selber noch nicht. Ich bin im Moment nur am Schauen/Analysieren ;-). A. K. schrieb: > Auf der Webseite finde ich keinen AVR32, bei dem eine FPU erwähnt wird. > Ich denke nicht, das Atmel sowas verschweigen würde. Ich finde nur > einiges Geschwurbel, das auf eine nicht näher dokumentierte zukünftige > Version mit FPU vertröstet. Das habe ich bis vor kurzem auch so gesehen. Dann habe ich aber jemanden getroffen der auf dem EVK1100 (Eval Board von Atmel) ein MP mit FPU hat (angeblich). Genauer weiß ich es auch nicht. Nur komisch, dass Atmel davon spricht, als ob es das schon gäbe: http://atmel.com/products/AVR/fpu.asp?family_id=607
A. K. schrieb: > Zukunftsmusik: > http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=32bitucfloating.htm Alles klar. Danke für den Link!
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.