[CALU] Re: Wir können und sollten uns einen zyklus bei teuren alu ops sparen
- From: Günther Wimpassinger <e0525147@xxxxxxxxxxxxxxxxxxxx>
- To: calu-ss2010-tuwien@xxxxxxxxxxxxx
- Date: Thu, 20 May 2010 19:09:14 +0200
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.
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:
