[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

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

--- Comment #33 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Jacob Lifshay from comment #31)
> 
> it is required in hardware that supports both endians since the byte
> reversal hardware is what changes wether little-endian or big-endian element
> indexing is used, by byte reversing inputs/outputs of operations (or any
> logically equivalent method that is likely much more efficient).
> 
> e.g., assuming your endian proposal with VL=4 r3=0x0123_4567_89ab_cdef
> sv.ori/sw=8/dw=16 *r3, *r3, 0
> in LE mode produces:
> r3=0x0089_00ab_00cd_00ef
> in BE mode produces:
> r3=0x0001_0023_0045_0067

Interesting example. I'll have to think about how I would implement that.

Ignoring BE for the moment, what kind of structure do you have in your design
for handling this kind of source/destination width mismatch? Is it something
like a bunch of multiplexers ahead of the ALU, or is there a more clever way to
do it?

> hardware would be something like (assuming registers and ALUs are in LE):

(Actually, registers and ALUs don't have endianness.)

In any case, I accept that Simple-V is already so incredibly complex that you
can't really afford the extra complexity of my idea. And if something like
sv.lhz/elwidth=16 gets things into registers in the right order in BE mode
(i.e. element-swapped compared with what a plain ld would do) then that answers
at least one of my main problems with saying the register file is always LE.

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