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

> byte order *is* significant in registers precisely because we can treat them
> as an indexed vector of bytes by using vector u8 instructions. having that
> vector of bytes match the vector of bytes in memory is important for
> performance and consistency, since otherwise we will have to insert tons of
> byte-swap instructions for memory-order bitcasting that would otherwise be
> totally unneeded.

no, you just use either ld-reverse or not.  the ld and st operation takes care
of the bytereversing, that's why it was added to OpenPOWER.

lhbrx and friends. p60 v3.0B spec.

we simply vectorise these, as-is.


> As far as I know, the plan is for scalar subvl=1 sources and destinations to
> read and write full registers, not just the first or last byte/u16/u32/u64.

... i almost thought you were saying the opposite here.

the rule is: elwidth=default means "do what OpenPOWER v3.0B normally does, and
do it EXACTLY and to the absolute letter of the spec".

therefore, in the divw example jacob gave: yes, the top 32 bits would be set to
zero 

however if you override elwidth=32 then *even when VL=1* the top 32 bits WILL
NOT be overwritten.

why?

because elwidth=32 is a SPECIFIC and direct command to the hardware to set the
underlying regfile SRAM write-enable lines  to 0b00001111

for elwidth=default those same lines are *categorically* and *always* wired to
0b11111111

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