[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
Mon Jan 4 05:52:07 GMT 2021


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

--- Comment #41 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
the reason for using the (hard) chosen convention of internal LE is down to the
way that nmigen refers to bytes and bits.

although it is a wiring decision which order to store in, it requires explicit
calling of a reversing function to get data into BE wire order with nmigen.

if that is to be optional then it is not hard wiring it requires a MUX array. 
if it is to be 1 2 4 8 byte reverse selectable that is a considerqble number of
MUXes.

the numbering of bytes in arrays in nmigen is LE ordered.

the arithmetic of the __add__ etc operators all assume LSB0 order

combining these two factors is why all data is stored in LE and processed in
LE.

it is why the data is converted out from memory as fast as possible from BE and
written to memory as late as possible to BE.

to add BE storage capability (the ability to perform byteswapping) to the
regfile would actually be an absolute bloody nuisance, plus it isn't in the
least bit clear how that could even be practical given how many possible points
such bytereversing could be targetted at.

to be "useful" it would require src and dest regs to have a bit each in svp64
to indicate that the operand was to be bytereversed, at the specified byte
size.

given that simply following the convention of bytereversing the data at the
load point gets you into natural arithmetic order of the HDL tool that we are
using i am really failing to see any benefit here to spending 3 to 4 bits on
something that can be dealt with at LD/ST time or, if it is absolutely
necessary arithmetically, to use bitmanip opcodes which perform bytereversal if
pushing through memory is undesirable.

things that have 10 to 30% usage are our highest priority.  5% is also worth
considering.

1% is only worth considering if it can be combined with 5 to 10 other 1%
savings.

it needs to be shown that, after the correct LDST is performed, there is still
a minimum 5% instructions that can be saved by adding the required 3-4 bits to
allow operands to be bytereversed.

plus taken into consideration what would be lost (removed from svp64) by doing
so, the penalty for that likely being far greater than a 5% saving.

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


More information about the Libre-SOC-ISA mailing list