[libre-riscv-dev] [Bug 305] Create Pipelined ALU similar to alu_hier.py

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=305

--- Comment #85 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #84)
> (In reply to Luke Kenneth Casson Leighton from comment #83)
> > um... um... it just occurred to me: if we detect that XER sticky overflow
> > is 1 in the ALU output stage, and if it is set (and required - insn.OE etc.)
> > only then do we even request a write to the XER.so register, then because
> > it is only setting, i do not believe we even need to read the XER.so at all.
> > 
> > as in: i think we can actually *remove* XER.so from ALUInputData, entirely.
> > 
> > this is because we don't actually care what the former value was - at all -
> > we are merely setting it.  and because that new value is *not* dependent
> > on the old value - at all - we don't need to waste that read port.
> > 
> > does this sound like a reasonable analysis?
> 
> sounds mostly correct to me, as long as the logic for setting CR0's 4th bit
> still reads the previous value when overflow isn't triggered.

that's the fly in the ointment.  i started removing SO and found that because
it is CR0's 4th bit, and because that 4th bit takes XER.SO as input
unconditionally as far as the calculation is concerned, XER.SO cannot be
removed from the input data structure for ALU.

now, it *can* be switched off by the *instruction* - Rc=1/0 - but not by the
ALU itself.


> SO is a prime
> candidate for some extra logic to allow multiple instructions to modify it
> each cycle.

as SO is being treated like any other register (despite it being only 1 bit
wide) it should be picked up by standard WaW (write after write) and unused
values thrown away.

-- 
You are receiving this mail because:
You are on the CC list for the bug.