[CALU] Re: Blockdiagram

  • From: Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Tue, 27 Apr 2010 19:06:23 +0200

On 27.04.2010, at 18:32, Günther Wimpassinger wrote:
Zitat von David Markvica <david@xxxxxxxxxxxxxxxxxxx>:

Hej!

Hab einen vorlaeufigen Entwurf mal ins git gestellt. Das sollt so ungefaehr das sein, was ich mim Bene zu mittag kurz besprochen hab..

Sachen die dabei aufgekommen sind:
- Stack ist im Daten-Memory, nicht in einem separaten Speicherbereich.

Die Speicherarchitektur ist mir sowieso noch nicht ganz klar. Spätestens beim Realisieren in HW werden wir sehen, was sich sinnvoll machen laesst.
Natuerlich kann man theoretisch den Stack und die Daten trennen, fragt sich, ob das bei unserer Architektur was bringt. Ok, Multithreading faellt ohne Manipulation des Stack Counters eh weg, und eine fixe Stackgroesse waer verkraftbar. Soviel internen Speicher haben wir andererseits auch nicht, und noch ein Speicherkontroller ist auch nicht gratis.

- 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.

- 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

lg, benedikt


Other related posts: