Hallo, wenn man den stack in den SRAM steckt hat das in meinen augen einen gravierende nachteile: bei ret, iret muß man die pipeline stallen bis die rücksprung adresse aus dem stack in den PC geladen wurde (das kann erst in der WB stufe geschehen. bei einem iret muß zusätzlich das predicate register gelesen werden (2 lesezugriffe im sram) wenn der stack separat ist könnte das wahrscheinlich schon in der ID stufe geschehen.
warum gibt es einen datenpfad von der alu zum PC? ich dachte wir arbeiten nur mit absoluten sprungadressen?
lg martin Am 27.04.2010 19:49, schrieb Benedikt Huber:
On 27.04.2010, at 19:27, Günther Wimpassinger wrote:Nein, eh nicht, aber ein nicht durchgefuehrter Memory-Store beeinflusst die Exec-Time.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?ah und, s/Constant Memory Consumption/Constant Energy Consumption/Es ist in dem Sinne schwieriger, dass (a) Forwarding vom Predicate beeinflusst und (b) auch Predicates geforwarded werden muessen.- 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 einfachDas ist genau so kompliziert wie Registerforwarding/ALU Result Forwarding, oder übersehe ich da etwas?Also etwas komplizierter, wenn du willst. Noch ein Beispiel: POPPREDS (p0)PREDSET x=0, p1 (p0) // Needs forwarding from MEM stage; the forwarding needs to take the old value of p0 into account XOR x,x,x (p0) // Needs forwarding from ALU (x=0); the forwarding needs to take the value of p0 from the stack into accountlg, benedikt
