[CALU] Re: [CALU]
- From: Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>
- To: calu-ss2010-tuwien@xxxxxxxxxxxxx
- Date: Sun, 11 Apr 2010 21:08:41 +0200
Hello,
On 11.04.2010, at 19:32, Martin Elshuber wrote:
Günther Wimpassinger wrote:
Hi Kollegas,
hab mir unsere ISA mal genauer angesehen.
Also die MULI(S) sind absout sinnfrei, denn wir können nur mit
Zahlen 0..15 oder -8..7 multiplizieren. Bei diesen Konstanten läßt
sich das immer mit 2-3 shift/sub/add Befehlen nachbauen (unsigned).
Signed hab ich nicht extra geprüft, sollte jedoch genau so sein.
Für die vorzeichenlose Division gilt das Selbe wie bei der
Multiplikaion mit Konstanten. Ausserdem benötigen * und / so viel
Zeit, dass ein extra MovI nicht sonderlich auffällt.
Agreed.
Ich würde in beiden Blöcken das I streichen und Mul/Div
zusammenführen. Dann untscheidet das "I" ob es sich um Mul oder Div
handelt. Den gewonnenen Platz würde ich wohl mit LoadByte und
LoadHalfWord ergänzen.
is ah recht.
eine weitere sinnvolle verwendung für den platz wären die shift ops.
die haben nur ein 4 bit immediate
Vote fuer LoadByte und LoadHalfWord.
AND/OR/NOR/XOR mit derart kurzen Immediates (ersten 5 Bits) halte
ich auch nicht besonders für sinnvoll. Ob die Einsparung etwas
bringt, ist ein anderer Fall. Eine andere Möglichkeit wäre
natürlich bei Immediate-Arithmetic-Instruction folgnedes Format zu
wählen, wodurch unsere Immediates um 4 bit länger würden (Sinnvoll?):
<pred> OP reg,imm
Semantisch:
reg:=reg op imm
ist eine überlegung
Wie schon in einem vorigen E-Mail erwähnt brauchen wir lange, bis
wir ein Register mit 32bit gefüllt haben, wenn wir den Wert nicht
aus dem Datenspeicher holen können. Habe nichts unter 10 Instr. auf
die Schnelle gefunden.
mit 9 hab ich eine
Hmm, da muessen wir was dagegen tun.
Eine Moeglichkeit waer eine non-predicated LDI Instruktion
einzufuehren, allerdings wird dass das Instruction Decoding wohl noch
ein wenig mehr verkomplizieren. Aber 9 Instruktionen sind schon sehr
viel fuer einen 32-bit wert.
Wie führen wir Instruktionen unbedingt aus? Damit noch weitere
Instruktionen ausgeführt werden, muss mindestens ein Pred-Regist
auf 1 sein. D.h sobald alle Pred-Regs 0 sind, haben wir nur noch
NOPs. D.h. nach einem Reset sind alle Pred-Regs auf 1.
man könnte auch ein predikat auf fixieren zb p15 oder p0
Ich denke, ein fixes Register mit Wert 1 ist eine gute Idee.
Wird unser INTR-Flag ein Teil des Pred-Regs? Wenn nicht, brauchen
wir zusätzliche Befehle zum Setzen/Löschen von InterruptEnable.
Ich glaube, die hatten wir vorgesehen. Bin gegen Teil des Pred-Regs.
Zu dem Scratchpad:
Da bin ich mir noch nicht ganz sicher, wie das funktionieren soll.
Was passiert bei einem Sprung auf eine Adresse die nicht im
Scratchpad ist? Was passiert, wenn die letzte "Zeile" Code aus dem
Scratchpad ausgeführt wurde?
Modulo Size, wuerd ich mal sagen.
Vielleicht sollten wir ueber die wichtigsten verbleibenden
Entscheidung noch abstimmen?
Hier ist noch mein erstes Beispielprogramm (Binary Search Single
Path), das vermutlich noch an die endgueltige ISA adaptiert werden
soll (C-Source ist im repository). Single-Path ~ Fuer eine fixe
Arraygroesse gibt es nur einen Ausfuehrungspfad. Man kann an diesem
Beispiel auch schoen beobachten, dass der Registerdruck bei Single-
Path Code ziemlich hoch ist.
; r0 = bs(int *r0, __attribute__((IDI)) r1, int r2)
SUBI r0, r15, 1
LDI r3, 0
ADD r7, r0, r15
BIP L2 (p15);
L1:
ANDI r6, r1, #1
LSRI r1, r1, #1
ADD r5, r3, r1
LD r4, r7(r5)
PREDSET p0, GT, r2, r4 (p15)
ADD r3, r5, r6 (p0)
PREDSET p0, EQ, r2, r4 (p15)
MOV r0, r5 (p0)
L2:
PREDSET p0, NEQ, r3, r15 (p15)
BIP L1 (p0)
L3:
RET
lg, benedikt
Other related posts:
