[CALU] Re: Instruction Set Encoding

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


On 09.04.2010, at 12:28, Elshuber Martin wrote:

griazi

Ich versuche schon seit längerer Zeit die Vorteile der AND, OR, PU zu finden. Tatsächlich läßt sich diese beispeil wunderbar rein mit UUs lösen

C-Code:
if(neg == 1) S1;
 ...
if(x > 0 && z > 0) {
  if(neg == 1) { S2 }
  else     { S3 }
else if(z<=0) {
  S4;
}

ASM:
    PRED (neg=1)  p0<UU>,p15<iUU>     ; p0=(neg==1)
(p0) S1
    PRED (x>0)    p1<UU>,p15<iUU>     ; p1=(x>0)
(p1) PRED (z>0) p2<UU>,p4<iUU> ; p2=(x>0)&&(z>0), p4=(x>0)&&! (z>0) (p2) PRED (neg=1) p2<UU>,p3<iUU> ; p2=(x>0)&&(z>0)&&(neg==1), p3=(x>0)&&(z>0)&&(neg==1)
(p2) S2
(p3) S3
(p4) S4
hi,
sieht fuer mich recht vernuenftig aus; der einzige drawback ist, dass man neg=1 nochmal berechnen muss, aber das ist wohl nicht so tragisch.


Wenn wir AND,OR und PU nicht verwenden wurden fürde uns alleine das schon 6 bits sparen (op_p1 kann auf UU, und op_p2 kann auf iUU) fixiert werden) Ein witeres bit könnte man einsparen wenn man das immediate auf 4 bit einschränkt. das 8te bit, könnte man entfernen indem man entweder das register ra oder (rb und immediate) auf 3 bits beschränkt, oder PREDI nicht mehr zulässt. die operationen PREDORx und PREDANDx wären ebenfalls obsolet. Voiala und schon haben wir 24Bit.
Ich faend es gut, wenn unsere Instruktionen etwas schlanker werden (eg, 24 Bit). Ganz unabhaengig davon, ist es nicht wirklich sinnvoll was zu implementieren, von dem wir nicht verstehen, wozu es gut ist.
Ein paar weitere Aenderungsdiskussionen zusammengefasst:
a) kein MOV
b) fuer shifts brauchen wir eigentlich nur immediates
c) fuer arithmetische Operationen wuerden kleinere immediates genuegen
d) Wie schaut es jetzt bit byteweisen und halfword load/store operationen aus? e) add LOADPAGE: Ich bin mir nicht sicher, ob eine Softwareimplementierung nicht ausreichen wuerde, aber wir koennen es ja vorerst mal drinnenlassen, oder?

Warum habe ich diese Variante gewählt?
Ganz einfach, weil es im Paper so beschrieben wurde, und weil es auch eine ISA (http://www.hpl.hp.com/techreports/93/HPL-93-80R1.pdf, Tabelle 12) gibt die das so löst.
Weitere Meinungen??

benedikt

Was machen wir?

Martin

Am 09.04.2010 09:56, schrieb Benedikt Huber:

On 09.04.2010, at 09:25, Elshuber Martin wrote:

Ich sehe jetzt im momment nicht viele Möglichkeiten wie wir, wenn wir bei predicates und fixed width ISA bleiben, bits sparen könnten. Das Flags-Bit sehe ich, zumidest am encoding Level, nicht als problem

das bottleneck ist allerdings die PRED instruction.
Koenntest du vielleich kurz illustrieren, warum die Wahl dieser Form von predicated instruction so genial ist? Fuer die einfachen Faelle braucht man IMHO nicht so ein kompliziertes System.
Wie schaut der Assembler fuer folgenden Code aus?
---------------------------------
> if(neg == 1) S1;
> ...
> if(x > 0 && z > 0) {
>    if(neg == 1) { S2 }
>    else     { S3 }
> else if(z<=0) {
>    S4;
> }
------------------------------
lg, benedikt

* wir fixieren uns auf einen 2-issue processor.
* wir führen 2 akkumulatoren ein (ACa, ACb, einer für jeweils eine pipeline)
* PRED ist ein instruction die nur alleine ge-issued weden kann
* die anderen instuktionen reduzieren wir so das 2 davon in die 32 bit passen. * wenn es wirklich eng mit den bits wird, kann man das F bit bei den meisten befeheln kicken

was meint ihr?
lg martin

Am 09.04.2010 08:50, schrieb Benedikt Huber:

On 09.04.2010, at 01:18, Benedikt Huber wrote:
- 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.
Um diesen Punkt noch etwas zu präzisieren: Lange Instruktionen haben ihren Preis: Der Prefetch dauert länger, wir brauchen einen größeren Prefetch Buffer (oder müssen öfter nachladen) und natürlich mehr Bandbreite um Instruktionen aus dem Buffer zu laden. Das jetzige Design hat für 32-bit relative wenige und recht einfache Instruktionen, und nützt bei vielen Opcodes einige Bits nicht (bei ADD werden z.B. 9 Bits nicht genutz)t. Ich denke, dass 4-bit oder 5-bit immediates auch ausreichen würden (wenn denn ADDI wirklich einen Mehrwert gegenüber INCR hat). Die klassiche ARM ISA mit 32-bit war übrigens nicht unbedingt die glücklichste Wahl, wie man an der Einführung von Thumb und Thumb-2 sieht.

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?
Ich denke es gibt zwei Möglichkeiten: Wenn wir während des Prefetchs blockieren, dann brauchen wir nicht unbedingt eine eigene Instruktion. Wenn wir paralell prefetchen wollen, dann schon.

lg, benedikt






Other related posts: