[Libre-soc-dev] XLEN in scalar spec pages

[Luke Kenneth Casson Leighton]

Paul, Toshaan,

just while i think of it there is an additional reason why the
pseudo-code of the spec should be altered to use a newly-defined
variable, "XLEN":

the Scalar Fixed-Point Compliancy Subset.

that's the basic summary, it should be obvious from that alone, but
for completeness / posterity i will write it out in full, below.

---

somewhere in the looong history of Power ISA i imagine that the spec
actually used to read, "all regs are 32 bit" and all pseudocode used
to have RT[0:31] etc etc.

somewhere along the line that got "upgraded" to 64 bit with the likely
assumption that nobody would be interested in going backwards in time,
heck, 640k is enough for everybody.

32 bit, i assume it was assumed, would be fine to run as "legacy"
applications, and consequently the 64 bit results were "munged"
(truncated) after computation.

except... as has been seen with both Microwatt and LibreSOC, the
resource utilisation of 64 bit on FPGAs is a whopping FIVE fold
increase over the equivalent RV32IM (32 bit, integer and mul/div)
resources.

this can be significantly reduced by halving the bitwidth of all ALUs,
regfiles, and datapaths.

this means that the Lattice ECP5 45K is 50% full, where it could
(might) be nearly 75% free.

the problem comes when a 32-bit implementor, with a *genuine
compelling resource* reason to do only 32 bit, looks at the spec, and
goes, "errr where's the 32 bit pseudocode"?

if the specification-compiler-simulator developed by LibreSOC can
actually execute 32 bit unit tests at the actual 32 bit width (not: 64
bit then truncate afterwards) then there is reasonable confidence that
the spec pseudocode is correct.

one last thing: it could be assumed that it is okay for 32 bit SFS
implementors to go back in time looking for very early Power ISA
specs, to find out what to do: this is not an option because the EULA
explicitly says "v3.0B" and the older specs will not even have the
newer opcodes (or other subtle changes / corrections).

deep breath, then: the spec pseudocode, 150 or so instructions, all
need to be updated to use XLEN and say XLEN=32 or XLEN=64.

with the simulator we have written being able to check that, it is not
as bad as it would otherwise be.

it would be necessary to start with the fixed point scalar because we
haven't yet completed scalar floating point.  this is partly underway
for Lauri to do MP3 SVP64 CODEC demo, but nowhere near robust and very
few unit tests.

l.