[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 #5 from Alexandre Oliva <oliva at libre-soc.org> ---
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?


GCC seems to regard vector types just like arrays, when it comes to memory
layout, so indexing it operates like indexing arrays.  this does mean, however,
that loading the vectors above from memory into a scalar 64-bit register will
land element [0] at opposite ends depending on endianness.  this is unavoidable
as long as you retain the property of in-memory indexing equivalent to that of
arrays, which also fits in with the notion of using neighboring memory areas
for neighbor vector elements, as the natural expansion of a sequential for-loop
vector load or store would use.

this does suggest that, in order to maintain the property I suggested, the
position and iteration order of sub-register elements may have to be affected
by vl, or even by both vl and maxvl, depending on endianness.

making it concrete:

if you take a zero-initialized vector, and use a byte-load instruction
svp64-prefixed with ELWIDTH=h ELWIDTH_SRC=default to load and zero-extend each
byte of a string into a half-word, and then store the registers holding the
vector in memory M[], should you get the string's bytes in M[odd] or M[even]
bytes?  should it not depend on endianness?

now, if your maxvl is 3, which pair of consecutive bytes in memory is
guaranteed to have zeros, M[0..1] or M[6..7]?

does the answer change if maxvl is 4, and but vl is still 3?

what if they're both 7?

does any of this conflict with any of the desirable properties you and I
brought up?

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