[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue Jan 5 16:27:12 GMT 2021


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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |RESOLVED
         Resolution|---                         |INVALID

--- Comment #84 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #82)

> still suffice since each individual byte can only be unswapped, 16-bit
> swapped, 32-bit swapped, or 64-bit swapped. no other combinations are
> supported/needed since they are ruled out by the natural alignment
> requirements.

this really needs diagrams to go over it.  i did a video, it is still uploading
(horribly slowly)

i think what you are suggesting is one of the following:

* to impose a restriction on the permutations permitted by the Dynamic
Partitioned SIMD ALUs (to 888888 16161616 3232 and 64) 

   this would, effectively at a specification level (conflating it with a
limitation at the hardware level) eliminate the possibility for Dynamic SIMD
ALUs to do 8888 in one half and use the other half for 32 bit, for example. 
or, 8-8-32-8-8

* assumption that the elements will start at an aligned boundary (every 64
bits) and therefore that the permutations need only cover 88888888 16161616
3232 and 64.

  which sounds reasonable until the merging of different operations occurs,
making use of empty lanes within the SIMD ALUs

now i have written them out those are the same thing.  i thought that one of
them might involve moing the dynamic byteswapping to be part of MultiCompUnit,
where the quantity of gates gets multiplied even more than it already is.

so, sorry, answer is no.  every way you look at it this is a total nightmare of
insanity.  it simply can't go in.

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


More information about the Libre-SOC-ISA mailing list