[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 #85 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #79)
> you may *think* the iteration order is already decided, but it really isn't.

we need to establish precisely where that lack of clarity exists, and word it
accordingly and provide diagrams.

> the specification is incomplete.  it's ambiguous.  it works both ways.  but
> one has to be chosen. 

that choice is - was - LE.  it was implicitly made as a choice because RISC-V,
which was when this was all originally designed, removed BE entirely from early
drafts of the spec, well before 2017 (RISC-II or RISC-III, i don't know which)

consequently it never came up.

> and if you say this was chosen a year ago, 

2 years ago.  2018?

> that's
> just not true, because it's evident that the issue wasn't even considered,
> let alone decided on. 

it was... but unfortunately it's become apparent that the typedef union, even
when it's mentioned that the underlying bytes are LE ordered, is insufficient
to be able to help people infer that.

what hasn't happened before is: because this is now OpenPOWER the idea to allow
element-level bytereversal has never been proposed before, so the lack of
clarity never came up. 


> now, one of them will make for reasonable compiler implementation.

the one that has been picked is identical to the one that was described by the
LLVM NEON article that Jacob found.  thus the expectation is that there will be
no complications.  it might not be nice (the article explains that there are no
nice choices), they had to pick the least-worst one.

the stackoverflow link i found shows that both NEON internal element order and
overall register byte numbering order are both fixed and hardcoded to LE.

now, it may not be clear (or accepted) that this is the case: it is however the
case.

this is not helped by the fact that it's obviously not clearly stated by the
ARM spec on NEON: outsiders from stackexchange had to *infer* this LE ordering
of both the registers and the elements by analysing the instructions and their
behaviour!

which is nuts, but it is what it is.

useful discussions from this point onwards involve clarifying exactly and
precisely any ambiguities in the spec that prevent people from understanding,
clearly and unequivocably, that we are doing precisely and exactly to the
letter what NEON does as "meaning" is concerned.

as best i can tell, a way to state that clearly and unambiguously is:

* the element ordering of NEON registers is linear and meaning is LE
* the ordering *in* elements within NEON registers has an LE meaning.
* the numbering of bytes comprising NEON registers *is* 0 refers to LSByte
* the numbering of bytes *in* elements is 0 refers to LSByte.

this is how it is in NEON. this is how it is in SV (with the overlapping).

is this clearer?

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