[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea

[bugzilla-daemon at libre-soc.org]

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

--- Comment #94 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
thoughts on whether this is practical (at the ISA level)

* LD 32 bit (lw) brings in data, scalar
* scalar is supposed to be identical to vector of len VL=1
* LD behaviour CHANGES to "do not do byteswap, this is now ALU/regfiles job"
* unfortunately all v3.0B is 64 bit not 8, 16 or 32.

which means that to "work" there would need to be a LD width "tag" propagated
to each regfile entry, just like in the Mill Architecture.

clearly that is unworkable (too radical a departure from OpenPOWER)

therefore the ALU/regfile bytereverse needs to be under EXPLICIT control of the
ISA.

we are NOT chucking in 4 bits into svp64 to cover this (dest-rev, src1-rev,
src2-rev)

however there is the Remap system and there is JUST about enough space there
https://libre-soc.org/openpower/sv/propagation/

the penalty (overhead) for setup of Remap however is a minimum of two 64-bit
instructions. immediate thoughts on that: tough.

however the really nice thing about Remap is the individual control over which
src and which dest registers get byte-reversed.

so the problem of LD/LDBRX bringing in data in one endian order then having to
swap it back, all that goes away because Remap can say "ok the LD operation did
the bytereverse on the src already, we just need to bytereverse the dest".

also Remap covers the order-inversion case of going from VL-1 down to 0... and
*again*: that may be selectively applied to src and dest, arbitrarily.

the penalty for doing so is that it must go through the massive cyclic shifter,
because the ordering does not match up with the backend ALU lanes.  again:
tough.

all doable, then, with caveats.

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