[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 #78 from Alexandre Oliva <oliva at libre-soc.org> ---
> 3) how both Jacob and Alexandre would *like* SV's regfile arrangement to work

please state for the record how you imagine *I* would like it to work, since
jumbling together what Jacob suggests and what I suggest seems to be leading to
confusion.

references to the comments in which you based your imagination would be
welcome.

hint: I have not suggested changes to the regfile arrangement.  not any.  not
one.

if you somehow got the idea that I did, we've miscommunicated, and you've been
opposing a strawman.



that you even think my understanding of ld and ldbrx insns is relevant WRT my
suggestion goes to show how deep the miscommunication goes.


that you insist the register file is somehow little-endian is as nonsensical as
insisting PPC bytes are big-endian regardless of the CPU endianness, or that
the bits in it are yellow rather than purple.  it's the sort of statement
that's "not even wrong": it starts from a fundamentally incorrect premise and
arrives at nonsensical conclusions because of it, but one that's not
disprovable because  it has no grounds in which to be assessed for truth. 
that's so because there's no addressing order of the bits or of the bytes
within a register to match or mismatch the significance order; all there is is
the significance order, which doesn't imply any preferential iteration order
for sub-units.

so, forget register endianness, even if just for the purposes of this
conversation, because it's not relevant for it.  convince me that it's
reasonable to deviate from the in-memory array iteration order that you've used
as the reference in the documentation, *or* that we're not actually deviating
from it.

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