[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 #31 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Paul Mackerras from comment #30)
> (In reply to Luke Kenneth Casson Leighton from comment #28)
> > checking (2) memory-to-register:
> > 
> > what about the same conditions (MAXVL=VL=1, a half-word load)
> > with lhbrx vs lhx?
> > 
> > * sv.lhbrx vs lhbrx, BE: same value loaded?
> > * sv.lhbrx vs lhbrx, LE: same value loaded?
> 
> What are you assuming the element size is?

i'd assume elwid=16

> I am not clear at this point on how the element size affects loads and
> stores. Does an element size of 16 bits mean that a load does 1/4 of the
> usual number of bits, for instance?

no, memory access sizes are not modified by elwid, so sv.lhz/elwid=16 still
loads 16-bits.

> You keep introducing byte
> reversal, which is not ever required by my proposal.

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

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

r3
|
| 0x0123_4567_89ab_cdef
v
rearrange all elements in BE order to LE order (a byteswap)
|
| 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef aka. 0xefcd_ab89_6745_2301
v
expand elements to 16-bit
|
| 0x0001, 0x0023, 0x0045, 0x0067, 0x0089, 0x00ab, 0x00cd, 0x00ef
| aka. 0x00ef_00cd_00ab_0089_0067_0045_0023_0001
v
4x ori with elwid=16
|
| 0x0001, 0x0023, 0x0045, 0x0067 aka. 0x0067_0045_0023_0001
v
rearrange all elements in LE order to BE order (like a byteswap)
|
| 0x0001_0023_0045_0067
v
r3

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