[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 #73 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #67)
> and just in case you're unconvinced because for 8-bit vector elements
> there's byte-reversing load, consider 16-bit and 32-bit vector elements,
> including floating-point ones; there aren't hword- and word-reversing loads,
> are there?

alexandre: this is so complex that it is critically important for you to
understand the basics - the scalar case - before moving on to the vector one.

also it is important to accept that the decision has been made: we are doing
what ARM has done for NEON which is exactly what intel did for MMX.

the only thing left for discussion is "why has that decision been made"

i will repeat it again to you both: there is absolutely in way in hell that we
are adding 2000 gates worth of dynamic switchable bytereversing in front of 40
regfile ports.  this is a final and irrevocable decision for which further
discussion along the lines of "are you sure, can i convince you otherwise" is
100% categorically going to meet with an emphatic and unchanging answer of
"never".

the LLVM NEON link that jacob found provides the guidelines on the approach
needed.

further fruitful discussion on this topic is best directed along the lines of,
"so the decision has been made, the regfile is LE Ordered, just like in NEON
and MMX, ok how do we fit things to that decision.  how do we clarify the spec
to fit that decision.  how do we implement that decision in HDL and the SV
simulators.  how do we best implement that decision in the compilers"

or, "i don't quite fully understand the decision, can you please explain it
again"

so please: can i ask you, alexandre, to follow along step by step through the
questions i am asking: do not add in vectors or any reference to vectors at all
in any way until the base frame of reference - OpenPOWER v3.0B - has been
understood.

there is an aspect of OpenPOWER that is critically important to understand and
accept when it comes to implementing the HDL, without which, as i have said
appx twice now, further discussion without a firm frame of reference is utterly
pointless, because it will only lead to "i cannot understand because of
assumption / miscommunication X".

please then: do not mention or discuss vectors further until scalar has been
understood and accepted.

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