[CALU] Re: [CALU] Re: Wir können und sollten uns einen zyklus bei teuren alu ops sparen

  • From: Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Thu, 20 May 2010 22:13:29 +0200

On 20.05.2010, at 19:09, Günther Wimpassinger wrote:
Zitat von Martin Elshuber <e9825286@xxxxxxxxxxxxxxxxxxxx>:
aller voraussicht werden wir bei der multiplikation 2 zyklen brauchen und bei der division noch mehr.
Ziemlich sicher sogar.

unsere derzeitige pipeline muss daher die pipline bei der multiplikation 1 zyklus lang stallen.

Darum wollte Benedikt das "DIV"/"DIVS" keine ALU Operation sind, sondern
ein externes per I/O angeschlossenes Modul.

IO-DIV (bei einem Store auf die 2te addr beginnt div zu arbeiten):
ldc r0,DIV_MODULE_BASE
st  r0,r5
st  r0+4,r6
;wait cycles- do other instructions
ld  r0,r0

ist das selbe wie, nur ohne pipeline stallt:
div r0,r5,r6

Jedoch muss der Programmierer dafür sorgen, dass sich die DIV Operationen nicht überschneiden.
Ja, ich denke ihr habt beide recht, bei DIV zahlt sich das via IO Modul aus, bei einer einfachen Multiplikation nicht. Martin meinte heute, man koennte u.U. das High-Word der Multiplikation auch als Memory-Mapped Register zu verfuegung stellen, was meiner Meinung nach ein weiteres nettes Feature waere. Zu den Optimierungen kann ich nicht viel sagen, ausser dass man den ldst Operand shift vermutlich in die Decode Stage ziehen kann, dass Multi-Cycle Paths eher haarig klingen und dass ich die Idee kleine Teile der ALU wenns was bringt zu duplizieren intuitiv gut finde.
lg, benedikt






wenn man sich darüber gedanken macht ist dieses stall meiner ansicht nach nicht nötig.

warum: was macht die wb stufe bei einer multiplikation? nichts.
(keine stack op, keine predikat op, keine sram op)

Das macht dir aber
a) einen comb. Pfad vom id2ex_reg ins Register File (der zwei cycles brauchen dürfte)

b) eine MUL Instruktion die über zwei Stufen ausgeführt wird. So zusagen wird in EX "mul_half" berechnet und in WB "mul_full".

Ich nehme an, du meinst sowieso die Variante "b"


zusätzlich könnte man auch den shifter genau so wie die multiplikation in 2 zyklen implementieren und den 2ten zyklus in der WB stufe ausführen

ALU_ADD,ALU_SUB,ALU_SLL stellt kein problem dar. Das zu synthetisieren bring mir ein Design mit ca 90 MHz. Ich werd mir am WE mal ansehen, wie das ist, wenn ich den "Pre"- Shifter für die Speicheradress Berechnung in ID verlagere oder eine eigene MEM_ALU mache. Auch gilt es zu testen, was passiert, wenn man ALU_MUL/ALU_DIV/ ALU_DIVS aus der Typdefinition löscht.

nicht müglich ist diese optimierung bei der addition da sie für die ld/st ops benötigt wird

wie ist eure meinung?






Other related posts: