[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 #76 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cole Poirier from comment #71)

> Luke, can you please respond exclusively to Alexandre’s above comment?

no, and i will explain why (for the third time).

Alexandre you are jumping the gun by proceeding to the vector case before you
have confirmed to me that you understand how OpenPOWER v3.0B scalar works at
the HDL level.

without establishing that common frame of reference there are zero answers,
there are only 100% disambiguating questions.



> You
> are addressing something that is not what he has written here and until this
> comment is addressed in isolation and point by point you will continue to
> misunderstand Alexandre.

no: i will continue to spend my time, just as i did in early comments, asking
questions that point out ambiguities which, because there is no established
common frame of reference, i am forced to ask, and which, because that common
frame of reference is not yet established, any efforts at communication are
100% ineffective.

we have three if not four or five separate discussions going on here

1) how OpenPOWER v3.0B Scalar works.

Alexandre has not established to me that he understands this and how it is
implemented in libresoc and microwatt

2) how SV's regfile arrangement works

this is LE and the decision here is categorical and final.  no amount of
discussion is going to change that decision.

3) how both Jacob and Alexandre would *like* SV's regfile arrangement to work

here the ideas are legitimate concerns but the complexity and cost is so high
it is just not going to happen.  not now, not ever.

continued efforts are ongoing to convince me of a decision that has already
been made, and ultimately it was the NEON LLVM link that showed me that a
software solution exists, and that no insertion of regfile byteswapping is
required.

it's not a "nice" software solution but it's infinitely better than ******g up
the hardware.

4) discussion of LE/BE vector ordering

these are just horribly confusing, having a minimum of *FOUR* separate and
distinct ways in which LE/BE could be applied.

(absolutely none of which are worth discussing because the decision has already
been made)


now, with so many separate discussions, none of which are clear (or being
accepted) the opportunities for cross-purposes are just nuts.

the discussion needs to be drastically cut back.  if that cannot be done very
quickly i am going to simply close - and lock - this bugreport.  i am not happy
about that however i have made it pretty clear how far behind we are.

discussions like this one when it has been made clear about eight or nine times
in the past 4 weeks that we are an entire year behind and need to get to
implementation as fast as possible, this means being extremely disciplined and
cutting stone dead unproductive discussions.

when we are this far behind i do not mind "how is this going to be implemented"
decisions.

major, major redesign suggestions, these are OUT.

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