[Libre-soc-isa] [Bug 569] svp64 register predicates vs BE arrays of bits

[bugzilla-daemon at libre-soc.org]

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

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
consider a case where processing of data requires LSB0 bit zero of
each element to become, ultimately, part of a predicate mask.  the most
logical thing to do is a Vectorised CMPI operation and the vector
of CR Field results treated directly as a predicate mask.

if however BE is involved then at least one reversal instruction is required

consider also the crweird instructions which transfer between integers and
CR fields: these too would become damaged by bit and/or byte reversal.

little-endian has an extremely important property in arithmetic field whereby
the bytes are in natural incrementing order that may take pairs, quads, or
any other multiple and regardless of that multiple the numerical RADIX
significance is still preserved.

BE does *not* hold this same property.  when constructing big integer
math libraries it is *not* possible to sequentially store an array of 64 bit 
numbers representing the large number then follow up with a typecast to
an array of 32-bit: you *have* to perform word-swapping on pairs of 32bit
numbers first to get the sequence back.

given the interchangeability between predicates and data it is simply
not safe or sane to attempt anything other than treating the regfile as
a byte-addressable LE-ordered SRAM.

having such a dedicated property ensures that changing elwidths does not
require such byteswapping instructions.

i appreciate that LLVM may have made some assumptions about SIMD, but tough.
when we have the prerequisite USD 25 million to do a decent job of adding
SVP64 to LLVM this can be addressed, and LLVM assumptions sorted out.
it is good to be *aware* of the limitations, because there will be no
surprises in budgeting to sort it out.

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