[libre-riscv-dev] [Bug 305] Create Pipelined ALU similar to alu_hier.py
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Wed May 27 18:46:10 BST 2020
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.
More information about the libre-riscv-dev
mailing list