[CALU] Re: Blockdiagram
- From: Günther Wimpassinger <e0525147@xxxxxxxxxxxxxxxxxxxx>
- To: calu-ss2010-tuwien@xxxxxxxxxxxxx
- Date: Tue, 27 Apr 2010 19:27:34 +0200
Zitat von Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>:
- Wir brauchen einen Speicherbereich auf den wir dummy-Stores
ausfuehren koennen wg. konstanter Ausfuehrungszeit.
Ich bin mir nicht sicher ob ich das richtig Verstehe. Es geht darum,
nicht benötigte Ergebnisse irgendwo hin zu speichern, weil das
predicate-bit nicht gesetzt war?
Fuer Constant-Execution Time / Constant Memory Consumption waere das
wohl notwendig.
Das verstehe ich nicht. Kannst du das anhand eines Bsp erklären?
Warum beeinflusst ein nicht verwendetes Ergebnis die Exec-Time oder den
Speicherverbrauch? Die Instruktion läuft trotzdem durch alle
Pipeline-Stufen. "Freimachen" einer Pipeline-Stufe, weil eine Ergebnis
einer Operation nicht benötigt wird, bringt auch nichts, da du die
Nachfolgebefehle sowieso nicht schneller durchschleusen kannst.
Das ist nur interessant für Instr. mit mehreren Taktzyklen. Und dafür
ist der Aufwand für diese LVA viel zu groß (IMHO).
- Sollten wir vielleicht nur den ALU-Operationen predicates
erlauben? Wenn wir predicated Loads haben, muessen wir
beispielsweise die ganze pipeline stallen, bis die durch sind.
Ich würde gerne die grundsätzliche Struktur der ISA nicht mehr
ändern. Das muss überall berücksichtigt werden. Ich hätte die
predicated instructions alle ganz normal ausgeführt und in der MEM
(bei Store) bzw. WB (bei allen anderen Instr) Stufe wird
entschieden, ob das Ergebnis übernommen wird, oder nicht. Branches/
Calls nicht berücksichtigt.
Prinzipiell ja.
Weiters muessen wir Predicates auch beim Forwarding beruecksichtigen,
falls wir das implementieren, und zwar in zweierlei Hinsicht:
Zum einen beim Forwarden von ALU / MEM Ergebniss fuer die naechste
und uebernaechste Instruktion, zum anderen die Modifikationen durch
PREDSET (ja, eigentlich wirken die sich erst in der WB Stufe aus,
aber mit Forwarding auch schon frueher).
z.B.:
XOR x,x,x
PREDSET x=0, p1 // Needs forwarded result of ALU operation (x ^ x)
ADD y,x,x (p1) // Needs forwarded result of ALU operation (x=0)
Mmh, dass wird wohl nicht ganz so einfach
Das ist genau so kompliziert wie Registerforwarding/ALU Result
Forwarding, oder übersehe ich da etwas?
Other related posts:
