[Libre-soc-isa] [Bug 567] Allow transparent scalar loads and stores to/from registers allocated as vectors

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=567

Cole Poirier <colepoirier at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |colepoirier at gmail.com

--- Comment #4 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (In reply to Alexandre Oliva from comment #1)
> > My recommendation doesn't involve changing loads or stores in any way.
> > 
> > My recommendation is that the svp64 iteration over sub-register vector
> > elements obeys the in-memory array/vector layout.
> 
> ok in standard vector terminology this is named "unit strided", and the
> pseudocode is as follows (i am drastically simplifying, taking out elwidths,
> predication, LE/BE, everything, stripping it back to fundamental basics):
> 
> [snip]
>
> correspondingly, when we get to element 1:
> 
> * L1.b0 = M15
> * L1.b1 = M14
> * L1.b2 = M13
> * L1.b3 = M12
> 
> 
> now we can finally see where the source of confusion about "The other
> choice" (MSByte0) is.  can you see that the ordering of the bytes with "The
> Other Choice" are absolutely *nothing* like those of the BE-ordered ld
> operation?
> 
> this despite the fact that the LD was a 64-bit LD.
> 
> i trust that this helps explain why NEON-like LE numbering for both elements
> and the bytes in the regfile has been chosen?
> 
> if that's clear then this bugreport can be closed as INVALID rather than
> DEFERRED, because there's nothing to change, no spec changes needed (only
> clarification).

Luke, this is *much* clearer than everything that exists on bug #560. Long
story short, if we want to catch up on the significant amount of work we lost
because of RV, we *MUST* keep bug reports focused to a single issue, and *MUST*
immediately migrate new and unrelated concerns to their own dedicated bug
reports without resistance. It is very clear that you cannot cope otherwise,
and this is highly detrimental to our productivity.

I think the above worked example explaining OP v3.0B unit striding is a very
necessary clarification/example and should be added to the spec to make it
clear for implementers, as given that it's taken a week to get to this point of
clarity for us, I imagine the vast majority of implementers will get stung by
this - potentially catastrophically.

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