I'd like to lift some ideas for the processing pipeline. I found it
easiest to sketch out the whole pipeline based on Tim's post and earier
model http://lists.duskglow.com/open-graphics/2006-August/006968.html
and incorporate the ideas there.
To summarise the pipeline stages:
1. Instruction fetch
2. Register fetch and branch condition
3. ALU
4. Memory IO
5. Write-back
The ideas are
* Move cheap unary operators from stage 3 to stage 2, e.g. istead of
implementing {add, sub} in 3, implement only {add} and optional
negation on one of the operands. The motivation is that parallel
functions in the ALU sits idle while one is working, and by moving
some computation to the previous stage we can instead exploit more
combinations.
* Let the ALU run independent of whether we do arithemetic or memory
operations. In case of memory operations, the output of the ALU is
the address, thus giving us more powerful addressing "for free".
For store, the second operand is the stored value so we need to
weaken the addressing by forcing immediate mode for the second
argument to the ALU.
* Only basic one-cycle operations goes in the CPU. If we need any
multi-cycle operation (div?), we could add it as IO ports, using
the "modularised RISC" idea,
http://lists.duskglow.com/open-graphics/2006-April/005307.html.
Below is the sketch. I hope you can read the Unicode. Some
conventions:
* I have taken the liberty to misuse logical operators as bitwise
logical operators.
* Conditional bitwise not:
(¬)^s x = | x if s = 0
| ¬ x if s = 1
1. Instruction Fetch
Fetch one instruction of the form (qmode, qop, ix, sx, mx, iy, sy, iz, c)
where
qmode 2 bits 0 = ARITH, 1 = FETCH, 2 = STORE, 3 = BRANCH
qop 3 bits ALU function if qmode ≠ BRANCH, else branch condition
ix 5 bits first operand register index
sx 1 bit first operand bitwise not option
mx 1 bit first operand increment by 1 option
iy 5 bits second operand register index
sy 1 bit second operand bitwise not option
iz 5 bits write-back register
c 9 bits immediate value
2. Register Fetch, Operand Computation, and Branch Condition
2a. Operand Computation.
Here we compute
x := (¬)^sx r_ix + mx
y := | (¬)^sy ⌊2^c r_iy⌋ if iy ≠ 0 and qmode ≠ STORE
| c if iy = 0 or qmode = STORE
If we expand the first on in terms of (sx, mx) we get the 4
operations:
x := | r_ix if sx = 0, mx = 0
| ¬ r_ix if sx = 1, mx = 0
| r_ix + 1 if sx = 0, mx = 1
| - r_ix if sx = 1, mx = 1
I assume splitting up negation into bitwise-not and increment does
not add significantly to the complexity. If that is not the case,
we should drop the mx from the instruction and simplify x to
x := (-1)^sx r_ix
Register r_0 is hardcoded to 0 for reads.
2b. Branch Condition.
do_branch := | false if qmode ≠ BRANCH
| x = 0 if qmode = BRANCH and qop_0 = 0
| x ≥ 0 if qmode = BRANCH and qop_0 = 1
The x ≥ 0 test is cheap (check upper bit). If the x = 0 test is too
expensive here, then we could add an equality comparison to the ALU
which returns -1 for true and 0 for false.
3. ALU
z := | x + y if qop = ADDSUB
| x ⋅ y if qop = MULT
| x ∧ y if qop = AND
| x ∨ y if qop = OR
| x ⊻ y if qop = XOR
| ⌊2^y x⌋ if qop = SHIFT
| ...
Note that the choice of x and y in SHIFT gives the maximum flexibility
by not duplicating the stage 2 shift operation.
4. Memory and IO
Optionally fetch from or store to local memory location z:
z' := z if qmode = ARITH or BRANCH
z' := M_z if qmode = FETCH
M_z := r_iy if qmode = STORE
5. Write-Back
r_iz := z' if iz ≠ 0 and qmode ≠ 11
We could add a bitwise-not here, and drop OR from the ALU, but I'm
running out of instruction bits.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
