[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 #23 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #20)
> (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.

no, you don't. bitcasting is a register reinterpret operation (register to
register), using load/store operations to implement bitcasting is slow and
wasteful (unless you needed to load/store anyway).

on LLVM, bitcasting usually compiles to no instructions, or rarely a register
to register move instruction.

> > 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

Well, I interpret elwidth=32 as a specific command to mean we operate on 32-bit
values, so scalars are truncated/sign/zero-extended to/from 32-bits when
reading/writing registers.

scalar registers are a *totally different kind* of argument, they are *not
vectors*, so therefore are treated like is usual in the scalar instruction set
-- registers are treated as a single value.

vectors (scalar with subvl!=1 counts as a kind of fixed-length vector in my
mind) treat registers as an array of elements, not as a single value.

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