[libre-riscv-dev] daily kan-ban update 12may2020

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue May 12 15:53:34 BST 2020

On Tue, May 12, 2020 at 3:29 PM Michael Nolan <mtnolan2640 at gmail.com> wrote:
> Yesterday I modified the ALU tests to read the alu inputs as specified
> in the instruction instead of hardcoded register numbers.

great.  i think we also worked out, it's kinda been a long-standing
convention that, instead of adding yet another 64 bit data path to
feed the ALU, the RB wires are used to feed in the immediate.

otherwise you have 64 wires for RA, 64 wires for RB, 64 wires for
RC/RS, and *another* 64 wires for an immediate.

so this is why i think you see the 6600, and RISC-V, and Power, and
many others, all never doing a 2nd reg (RB) *and* an immediate.
there's a *third* register - RC - in the case of POWER, because unlike
RISC-V which seems to be based around 2-64-bit-inputs (except FMAC),
and 1-64-bit-output, POWER seems to be based around a much more
complex 3-64-bit-datapaths-in and up to *two* 64-bit-datapaths-out....
*plus* Condition Registers in and out.

> I refactored
> the test to greatly reduce the amount of time it takes to run (went from
> ~1m to ~3s on my computer)
> Today I'd like to split out the shift and rotate instructions into their
> own separate FU

i think that will help make things clearer, and the actual ALU code in
each module a lot shorter.


More information about the libre-riscv-dev mailing list