Mehr als eine "Instruktion" pro Takterereignis?

[_self (Gast)]

Hey, ich lese gerade das Datenblatt zum ATMega8 und wundere mich etwas 
darüber, dass der ALU offenbar mehrere -nun ja, am ehesen würde ich sie 
Instruktionen nennen - pro Taktereignis ausführen kann.
Hier sieht man im Dokument 
(http://www.atmel.com/images/atmel-8159-8-bit-avr-microcontroller-atmega8a_datasheet.pdf, 
S. 30), dass der Alu innerhalb von einem Takt sowohl die Operanden 
einliest, die Rechenoperation ausführt wie auch das Ergebnis 
zurückschreibt. Wie funktioniert sowas auf Hardwareebene? Wird der Takt 
irgendwie verzögert auf Subschaltkreise des ALUs weitergeleitet?
Mit freundlichen Grüßen

[Jacko (Gast)]

Das eine geschieht bei der negativen Clock-Flanke,
das andere bei der positiven Clock-Flanke.

Wenn ich mich recht entsinne...

[Max M. (jens2001)]

_self schrieb:
> dass der ALU offenbar mehrere -nun ja, am ehesen würde ich sie
> Instruktionen nennen - pro Taktereignis ausführen kann.

WO???? liest du das?

Fetch, Execute und Writeback sind EINE INSTRUCTION!

[(prx) A. K. (prx)]

Da steht keine Subtakt-Sequenz oder Delayline dahinter. Wie man schon am 
Bild darüber erkennt, sind die dicken Teile der Balken jene Phasen, in 
denen dieser Teil der CPU relevant ist. Der Rest ist kein 
Tristate-Zustand, das sieht aufgrund der an Buszustände erinnernden 
Darstellung nur so aus.

Aus dem Registerfile wird in der ersten Takthälfte gelesen, danach 
bleiben die Daten stabil. In das Registerfile wird nur in der zweiten 
Takthälfte geschrieben, was davor kommt wird ignoriert. Die ALU 
verbindet die beiden Read-Ports mit ihrer Operation mit dem Write-Port. 
Bevor die Daten aus dem Registerfile da sind und durch die ALU durch 
sind liefert die ALU Schrott, aber das stört nicht.

[_self (Gast)]

Danke für die Antworten!

[Tim . (cpldcpu)]

https://de.wikipedia.org/wiki/Pipeline_(Prozessor)

[(prx) A. K. (prx)]

Nur ist das, worum es hier gerade geht, keine Pipeline.

[Tim . (cpldcpu)]

Das Bild ist gemeint?

Das ist ein rein kombinatorischer Vorgang. Erst der Write-Back führt 
wieder zum latching der Daten. Da nichts besonders dran und es sind auch 
keine "sub-clocks" notwendig.

Natürlich erlaubt eine solche Architektur keine sehr hohen 
Taktfrequenzen, aber das ist beim AVR wohl egal, da er sowieso durch da 
langsame Flash begrenzt ist.

[Axel S. (a-za-z0-9)]

Tim  . schrieb:
> Das Bild ist gemeint?
>
> Das ist ein rein kombinatorischer Vorgang. Erst der Write-Back führt
> wieder zum latching der Daten. Da nichts besonders dran und es sind auch
> keine "sub-clocks" notwendig.

Yep. Etwas irreführend an dem Bild ist, daß das Lesen der Operanden, die 
Verarbeitung und das Writeback so dargestellt ist, als wären es drei 
separate Vorgänge. Sind sie nicht. Das passiert alles gleichzeitig. Am 
Beginn des Zyklus schaltet ein Multiplexer die beiden Operanden auf die 
Eingänge der ALU. Die ALU selber führt praktisch ununterbrochen ihre 
Arbeit durch (ein paar Bits aus dem Befehlsdecoder sagen ihr dabei, was 
genau sie  tun soll, z.B. ADD oder AND). Und am Ende des Zyklus wird das 
Ergebnis aus der ALU im Zielregister gelatcht.

> Natürlich erlaubt eine solche Architektur keine sehr hohen
> Taktfrequenzen

Entscheidend ist nicht die Taktfrequenz, sondern der Durchsatz. Wenn man 
mehr Verarbeitungsschritte asynchron macht, dann braucht es wegen der 
Laufzeiten natürlich länger, bis das Ergebnis "steht". Wenn man die 
Verarbeitung in kleinere, taktsynchrone Einheiten aufteilt, dann wird 
zwar jede Einheit für sich schneller fertig, aber die Instruktion 
braucht am Ende genauso lange oder sogar länger.

Klassisches Beispiel ist Z80 vs. 6502. Der erstere ist synchron 
aufgebaut und braucht entsprechend mehr Takte pro Instruktion. In der 
Praxis sind ein Z80 bei 2.5MHz und ein 6502 bei 1MHz ungefähr gleich 
schnell.