[Libre-soc-isa] [Bug 905] create Scalar reg access encoding (SVP64-Single)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #3 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Jacob Lifshay from comment #2)
> > 
> > totals 21, 3 spare. EXTRA5? leave as reserved?
> 
> imho we should leave as reserved because that reduces the amount of space
> required to 1/4th (accounting for 2 saturate bits) as much as svp64, greatly
> reducing opcode pressure.

though maybe use 1 bit so loads/stores can be pc-relative, like the v3.1
prefix's R bit. this can greatly reduce needed instruction counts to access
constants/variables, though imho we should differ from v3.1's R bit:
we should always add (RA|0) and just tack on CIA as a new addend, rather than
replacing (RA|0) with CIA, this allows stuff like keeping jump tables and other
lookup tables easily accessible:

pseudocode i'm proposing for SV-single:
if SVSR = 0 then  # SV-single's R field
    addr <- (RA|0) + EXTS64(D)  # normal ld/std
else
    addr <- CIA + (RA|0) + EXT64(D)  # pc-rel ld/std

note that the CIA + D add can be done well before the execute stage, since both
are known values at the decode stage, avoiding extra latency due to more
complex addr calculation in ld/st pipe

example jump table with pc-rel, r3 on input is 0, 8, or 16:

table:
.long label1
.long label2
.long label3
...
code:
svs.ld r3, table at pcrel(r3), 1
mtctr r3
bctr

equivalent v3.1 code:
table:
.long label1
.long label2
.long label3
...
code:
paddi r3, r3, table at pcrel, 1
ld r3, 0(r3)  # can't use pld R=1 since it ignores input registers
mtctr r3
bctr

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