[CALU] Re: Instruction Set Encoding

  • From: Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Fri, 9 Apr 2010 01:18:34 +0200

On 09.04.2010, at 00:01, Elshuber Martin wrote:
Ich habe gerade eine Vorversion des Instruction-set-Encodings ins Repo getan.
hi martin,
danke fuer die muehe.
Ein paar Fragen:
- Wollen wir jetzt doch branch prediction mitreinnehmen?
- 24bit pro Instruktion war kurz im Gespraech - ich nehm an dass geht sich nicht aus? Ich hab so das Gefuehl, wir relative grosse Instruktionen fuer einen RISC haben auf diesem FPGA haben. - Die Predicated Execution Maschinerie find ich schon recht heftig und etwas dominant im Design. Ist die Kombination der 'update flags' varianten und den Predicate Tests sinnvoll? - Kannst du kurz erklaeren, wozu die Op_px Dinger (unconditional, inverted unconditional, etc.) praktisch gesehen gut sind? Ist mir noch immer nicht klar.
Bezüglich der Memory-operations habe ich aber keine Ahnung wie wir das Addressieren wollen Ich hab jetzt mal 2 Arten gemacht. (base+(register<<shift)) und (base +immediate)
hmm, was waere ein typischer use case fuer den shift?
was wir uns auch noch nicht ueberlegt haben, wie schaut es mit LOADBYTE und LOADHWORD aus? Wollen wir sowas?
Die Instruction "loadpage" ist mir auch noch unklar. Wie groß ist eine Page? Wie schaut das Alignment aus?
Ich wuerd sagen 32-64 Instruktionen ist eine vernuenftige Groesse, wir muessen halt bedenken, dass wir der load selbst
auch ein paar instruktionen braucht.
Wenn wir ein ROM implementieren, könnten wir diese funktionalität auch über eine Schleife im ROM lösen.
du meinst load page? ja, waer auch eine idee. was sind die tradeoffs?

lg, benedikt
Bitte schaut mal nach ob ich eh nichts doppelt belegt habe.

Ich habe versucht die Bedeutung möglichst vieler Bits invariant über möglicht viele Instruktions-Typen zu lassen um das ID zu vereinfachen.

lg Martin


Other related posts: