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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Wed Dec 30 22:28:28 GMT 2020


--- Comment #7 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Alexandre Oliva from comment #5)
> the property I mentioned in comment 3 may seem a given for 64-bit ELWIDTH; I
> failed to mention here that the concern was about sub-register element types.
> as for the property you wrote about in comment 4, jacob, I'm having some
> trouble figuring out just what you mean.  to illustrate, say you have an
> 8-byte string, or a 4x16-bit (x,y,z,w) tuple held in a 64-bit register.  now
> you store that register in memory, and load it back, as a vector of 8 bytes,
> or as a vector of 4 halfwords, onto a different register.  then you compare
> both registers as scalars, and they should compare equal, is that what you
> mean, or is there more to it, i.e., something about their maintaining the
> same relative positions regardless of endianness?

a concrete example:
if the memory at *r3 is:
0x01 0x23 0x45 0x67  0x89 0xAB 0xCD 0xEF
0xFE 0xDC 0xBA 0x98  0x76 0x54 0x32 0x10

setvli r0, 16
ldb r16.v, (r3.s)
setvli r0, 2
std r16.v, (r3.s)

should overwrite the memory at *r3 with the same bytes that were already there.

if the processor is in big-endian mode:
r16 == 0x0123456789ABCDEF
r17 == 0xFEDCBA9876543210

if the processor is in little-endian mode:
r16 == 0xEFCDAB8967452301
r17 == 0x1032547698BADCFE

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

More information about the Libre-SOC-ISA mailing list