[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 #105 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #103)

> it's worth pointing out that you are not the only one on this project,

i am however the only one actually doing actual full time work.
if you had actually been helping out over the past 2 years as i hsve been
asking for 2 years that you actually do, i would be much more inclined
to listen because i would feel that i had time to do so.


> it changes how sub-registers are addressed, 

which is low level in the extreme and thus requires an extreme and thorough
assessment.

> everything else remains
> unchanged. Imho this is far from the most confusing part of SV (the most
> confusing part for me is probably vertical-first mode, or maybe the other
> FFT stuff).

it took me 2 years to realise what Mitch Alsup was talking about.
REMAP is a hardware function which remaps the element order *and*
can byte-reverse the access to element data from the regfile.

> 
> > also i said that the task has to include a full and complete comparative
> > analysis against using the existing solution (LDST-bytereverse (ldbrx)
> > when Vectorised, plus the Bytereverse mode of REMAP).
> > 
> > in addition to that we cannot keep on adding features (especially high
> > impact fundamental low-level ones like this which take up huge amounts
> > of time even just to assess).
> 
> Well, I do think we will want this feature in the end (the ISA WG may also
> demand it for consistency with the rest of the ISA), 

i am not going to let the VSX mindset poison SVP64.  just because IBM added
something in VSX does *not* automatically make it a good idea to add to SVP64.
far from it: i take it as a sign that it should NOT go into SVP64.

> and the longer we put
> this off, the harder it is to implement and the more work will be wasted
> trying to work around the lack of this feature.

ldbrx.

REMAP.

please take the time to properly assess those first.

aiuui REMAP actually already does exactly what you want: it performs
an EXPLICIT byte-reverse at the element level on register read and
register write.

aiuui what you are asking for is IMPLICIT bytereversal, which makes
me extremely nervous as it is a hell of a large impact.

> Therefore, I think it's worth me spending a few weeks trying to implement in
> the simulator and testing it out, etc.

i suggest that you first help by implementing the byte-reverse mode of REMAP.
rhis will also help you to understand REMAP itself.

then you will be in a strong position to understand it, and will not
waste time implementing something that turns out to be unnecessary
only after several weeks of work.

also once REMAP byte-reverse is implemented it will be *possible* to
hook in to test what you want to test.

also worth pointing out: elwidth overrides are needed first, long before
this work can be attempted.

without elwidth overrides there is the risk that unit tests would not
pick up errors where data went in the wrong byte.

given the frickin MSB0 ordering of Power ISA the probability of that
occurring is extremely high.

so.

task order is:

1) elwidth overrides (pseudocode, Simulator)

2) huge paranoid number of elwidth unit tests

3) bytereverse REMAP mode (on both read and write to regfile)

4) implicit bytereverse mode.

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