[CALU] Re: Blockdiagram

  • From: Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Wed, 28 Apr 2010 11:22:00 +0200

On 28.04.2010, at 10:59, Elshuber Martin wrote:
Hallo, wenn man den stack in den SRAM steckt hat das in meinen augen einen gravierende nachteile:
Hallo Martin,
natuerlich ist es am einfachsten, alles als internen Speicher zu realisieren. Wenn wir genug Platz haben, spricht auch nichts dagegen im Rahmen der Uebung.
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.
Naja, gravierender Nachteil, 2,3 zusaetzliche Zyklen bei einem Call/ Return meiner Meinung nach schon vertretbar, aber da die ganze Sache dadurch wohl kompliziert wird, hab ich keine 'strong opinion'. Vielleicht koennen wir das auch heute bei der Abgabe mit Wolfgang andiskutieren (ich weiss, du kannst heute nicht)
lg, benedikt

p.s.: In der isa-final.tex haben noch die predX Instruktionen gefehlt, ich hab sie hinzugefuegt. Im uebrigen: latex-foo 1a, respekt.
p.s.s: Ich bin in der woche vom 10.5 zum 15.5 nicht in Wien, fyi



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:

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?
Nein, eh nicht, aber ein nicht durchgefuehrter Memory-Store beeinflusst die Exec-Time.
ah und, s/Constant Memory Consumption/Constant Energy Consumption/



- 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?
Es ist in dem Sinne schwieriger, dass (a) Forwarding vom Predicate beeinflusst und (b) auch Predicates geforwarded werden muessen.
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 account
lg, benedikt



Other related posts: