[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

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

--- Comment #28 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #9)
> "Register files, elements, and Element-width Overrides" section:
> 
> I strongly disagree that the register file should be accessed in
> little-endian byte order when the processor is in big-endian mode.

just to check (1) register-to-register,
(note deliberate use of "addi" in 3rd step):

* let us set MAXVL=VL=1
* let us also use elwidth=16
* let us set (verilator or "addi 5,0,0x1234") the contents of GPR(5) = 0x1234
  LSB0 63..........0
  MSB0 0..........63
       0000... 12 34
* perform "sv.addi/elwidth=16 5,0,0x1122"
* then inspect (verilator) GPR(5) and read its contents

is the answer you expect, regardless of LE/BE: 0x2356?
(or would it be 
* 0x2211_0000_0000_1234 (or 0x1122_0000_0000_1234)
* 0x0000_0000_0000_3456 due to addi being different from sv.addi under BE?

now the same thing with *scalar* instructions:

* let us set (verilator or "addi 5,0,0x1234") the contents of GPR(5) = 0x1234
* perform "addi 5,0,0x1122"
* then inspect (verilator) GPR(5) and read its contents

is it *still* 0x23567 regardless of LE/BE?


checking (2) memory-to-register:

what about the same conditions (MAXVL=VL=1, a half-word load)
with lhbrx vs lhx?

* sv.lhbrx vs lhbrx, BE: same value loaded?
* sv.lhbrx vs lhbrx, LE: same value loaded?



if the answer in all cases (m2r&r2r) is "yes", then this is what i mean
by "instructions must be Orthogonal regardless of Prefix/Non-prefix"

if the answer in all cases is "no", then resisting the pressure
to break Orthogonality, these are some potential options:

* solution (1) is to add *scalar* instructions that perform the BRev
  (and then SV-Prefix those)
* solution (2) is to add *scalar* register-tagging (an SPR that
  marks a given register as "please reverse me on GPR read *and* write"
* solution (3) is to completely redesign the 24-bit SVP64 Prefix
  from scratch, reserving four bits for being able to reverse
  up to 4(!) operands (coping with FMAC)
* solution (4) just use in-place sv.brh *RT, *RA (where RT=RA)
  and go from there

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