[CALU] Re: (No Mime-Version: 1.0 (Apple Message framework v936)

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

On 13.04.2010, at 23:35, Günther Wimpassinger wrote:
Hallo alle,
ein paar kurze Anmerkungen. Ich werde dann deine Votes in einer weiteren Mail mit meinen zusammenfuehren.

nachdem ich es jetzt endlich geschafft habe meine Funktionen zu implementieren will ich hier meine Eindruecke unserer ISA und die Zusammenfassung unserer Diskussionen darlegen.

Die Multiplikation habe ich so implementiert, dass das Produkt 32bit gross ist. Wenn wir das auch so in der Hardware machen, dann ist es nicht notwendig zwischen unsigned und signed multiply zu unterscheiden. Und es sind recht schlanke Funktionen geworden, wie ich finde. Ich hoffe nur, dass sich kein Fehler darin verbirgt.

Bei der Division ist mir aufgefallen, das wir keine Modulo-Operation in der ISA haben. Sollten wir evtl. doch noch eine Mehrtaktdivision implementieren, dann ist die Modulo-Operation quasi geschenkt. Bei "div" lassen sich die signed/unsigned Varianten nicht zusammenfuehren.

Das "setze Flags" bei arithmetischen Operationen ist, soweit ich das durch meine Beispielprogramme beurteilen kann, notwendig. Ich mache davon bei "div" Gebrauch.
Dass hab ich noch nicht gemacht, aber es ist klar, dass Loops mit einem festen Iteration-Count dadurch um eine Instruktion kuerzer werden.
==========
Zusammenfassung der Diskussion:
-) Enable/Disable Interrupt Instruktion STI/CLI
-) Wir streichen MULI* und DIVI*
-) Wir fueren LB, LBS, LHW, LHWS Instruktionen ein
   Byte und Halbwoerter muessen nicht ausgerichtet sein,
   Doppelwoerter hingegen an 2 Byte Grenzen, wenn wir 32
   bit Zugriff auf SRAM lassen. -) Ein Predicate ist immer auf 1 (p15)
-) Wir benoetigen Predicate-Define Befehle fuer "register CMP register" und
   "register CMP immediate".
Ja, vorallem wenn wir kein 0-Register haben (was Sinn macht, wenn es viele immediate Varianten gibt
-) Den Vorschlag von benedikt fuer die Predicate-Define Befehle finde ich OK, auch wenn ich zur Zeit noch den "alten" 24bit ISA Satz verwendet
   habe.
-) wir haben KEIN 0-register.
Find ich auch ok. Hatten wir das schon diskutiert?
-) wir haben static branch prediction (brach possible bit in der Instruktion) -) ALU Flags werden an bestimmte predicate register weiter geleitet, wenn in der Instruktion angegeben.
p0-p3? Da ja predicates bei komplexen if-then-else Bloecken stackartig wachsen, koennte man p15 = 1, und dann p13-14, p11-12, etc. fuer jedes nesting level verwenden.

=============
Ich habe Vorgeschlagen, bei manchen Instruktionen mit Immediates statt
ra <= rb OP im, ra <= ra OP im zu verwenden, damit die Konstanten laenger werden. Dass heisst aber automatisch dass ein "addi r0,r2,0" als move-Ersatz nicht funktioniert. Bei Add/Sub reichen die kurzen Immediates meiner Meinung
nach.

Bei OR/AND/NOR/XOR haben die kurzen Imms kaum Sinn. Mir faellt im Moment keiner einer.
Eine moegliche Variante fuer 5 bit (nach den Erfahrungen mit den Algorithmen) waere:
  op := AND | OR | NOR | XOR
op 1 b3 b2 b1 b0: rd = ra `op` (0xb3b3b3b3b3b3b3b3b2b2b2b2b2b2b2b2b1b1b1b1b1b1b1b1b0b0b0b0b0b0b0b0)
  op 0 b3 b2 b1 b0    rd = ra `op` (1 << (b3b2b1b0))
Dann mit laesst sich realisieren:
 - Bittest, Bitset, Bitflip
 - MASK for bytes, halfwords and words
 - XOR with 0 and ~0 for bytes, halfwords and words
============

Wir brauchen unbedingt eine Instruktion die laengere Immediates laden kann.

Schlecht waers nicht.
Ein Vorschlag war eine "unpredicated load constant" instruction. Meine zwei Vorschlaege, oder eher hacks, lauten wie folgt:
(a)
-) Wir definieren ein bestimmtes Predicate immer auf 0
Bin ich dagegen; ein ganzes predicate nur fuer nop ...
-) dadurch kann ich jede beliebiege Instruktion zu einem NOP machen
-) das aktuelle NOP wir zu einem LoadConstant in ein bestimmtes Register, wobei
  23:20 predicate
     19 1 (immediate)
  18:14 OPCODE 00000
  13:12 position
  11: 0 immediate

 semantik:
  position=b00 => r0 = immediate (mit sign extension)
  position=b01 => r0 = ro | (immediate << 12) (mit sign extension)
position=b10 => r0 = ro | (immediate << 24) (kein sign ext. notwendig)
Huh, das klingt ziemlich haarig zum decodieren. Aber load constant mit shifts ist keine schlechte Idee.
Ginge sich irgendwie 16-bit- plus 1 shift bit aus?

(b)
-) Die aktuelle NOP Instruktion ist nur dann ein echtes NOP wenn im Predicate-Teil (23:20) p0 steht. Sonst eine LoadConstant Instruktion. Beispielsweise wie bei (a).
Nett formuliert :) Aber wo genau ist da der unterschied zu einer (predicated) Load Constant Instruction ?

=========================
Wir haben 52 4096 Bit Speicher am Cyclone, 512Byte, 128DWord/Memory.

x1 Speicherbloecke als STACK mit fixer Groesse
x2 Speicherbloecke fuer BIOS/Programm direkt am FPGA (mit Quartus raufspielen) x3 Speicherbloecke als Instructionscratchpad, in dem Teile des aktuellen
  Programmcodes stehen, welcher ausgefuerht wird.

Derzeit gehen wir noch von einer "von Neumann" Architektur aus. Wenn wir das aendern, wir unser Instructionscratchpad zum Program-Memory und das SRAM zum Daten-Memory Dann wir der Speicherblock fuer BIOS die komplette Anwendung.

Bleiben wir bei von Neumann, muss es eine Moeglichkeit geben, Instruktionen in das Scratchpad zu bringen.
Wie genau/ungenau machen wir das jetzt mit dem Instruction-Scratchpad?
Ungenau:
LOADPAGE r, imm :=
   page[imm] = mem[r..r+PAGESIZE-1]

benedikt
  • References:
    • [CALU]
      • From: Günther Wimpassinger

Other related posts:

  • » [CALU] Re: (No Mime-Version: 1.0 (Apple Message framework v936) - Benedikt Huber