[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

Jacob Lifshay <programmerjake at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake at gmail.com

--- Comment #84 from Jacob Lifshay <programmerjake at gmail.com> ---
(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. SO is a prime
candidate for some extra logic to allow multiple instructions to modify it each
cycle.

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