[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Wed May 31 17:52:13 BST 2023
--- Comment #39 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #24)
> The ISA as it stands has a property which is extremely useful, which is that
> with a couple of rare exceptions (see below), it is possible to analyse an
> instruction word (or doubleword) and know which CPU registers it is going to
> read and write, without knowing anything about the architected state of the
sigh, yes - the exception to that being the contents of MSR.
(MSR.LE, MSR.SF, and others). SVSTATE has to be similarly
considered "a peer of MSR and PC" (and SVSHAPE0-3 if REMAP is
implemented, typically in 3D GPUs, HPC, and high-end A/V DSPs)
in Libre-SOC's HDL i have a special "regfile" containing
PC,MSR,SVSTATE,DEC,TB and when REMAP is implemented SVSHAPE0-3
will have to join them
> This simplifies the job of anything that wants to translate or emulate
> instructions, or generally understand what the effect of a block of code
> could be or the dependencies between instructions. Examples include
> valgrind, qemu, gdb, etc.
luckily the register EXTRA information is in the SVP64 24-bit Prefix.
otherwise we _would_ be in trouble, there.
(btw heads-up, the concept of "streaming" utterly borks that. ARM SVE
has "streaming" coming. https://arxiv.org/pdf/2002.10143.pdf)
> [The exceptions are the lswx and stswx instructions, which use a byte count
> in the XER. The byte count controls the number of GPRs read or written. But
> modern compilers don't use lswx or stswx, and they always cause an alignment
> interrupt in LE mode.]
they were great when CPUs were 130 mhz and single-issue. multi-issue it
all goes to hell-in-a-handbasket and (following comp.arch regularly)
general consensus is LD/ST-Multi is history.
of course total irony then that Simple-V would *accidentally* re-introduce it:
sv.ld/sm=r10/els *RT, 0(RA)
> If a side effect of adopting Simple-V is that this property no longer holds,
> then that is a serious problem in my view.
> If it is the case that a 32-bit
> instruction without any prefix could in some cases access different
> registers from those identified in the instruction word, depending on the
> state of the CPU (for example, depending on what is in the SVSTATE SPR),
> then you have broken this property.
> I had thought there would be a clear and simple way to tell which
> instructions would be affected by vectorization (i.e., the presence of a
> SVP64 prefix).
all of them! okok - everything-that-makes-sense. mtmsr makes no sense.
sync makes no sense.
> But it sounds like that is not true, unfortunately.
it is... but i had to encapsulate it in a program (i sure as hell wasn't
going to do it by hand).
this program *is* reasonably-obvious, the key function being "create_key()"
which analyses all instructions (remember i mentioned turning decode1.vhdl
into CSV files?) and then creates a "Register Profile footprint" (aka key)
that can be used to decide what bits in the 24-bit Prefix are to be used
to extend registers RT RS RA RB RC BA BFA BB BT FRT ...
sv_analysis.py does actually generate markdown tables so you can see what
anyway - back to the registers: a reasonable way to think of the RTL is
that when Prefixed, all the registers have been "shifted" into a new
616 * maddhd RT,RA,RB,RC
620 prod[0:(XLEN*2)-1] <- MULS((RA), (RB))
621 sum[0:(XLEN*2)-1] <- prod + EXTS(RC)[0:XLEN*2]
622 RT <- sum[0:XLEN-1]
620 prod[0:(XLEN*2)-1] <- MULS((SVP64.RA), (SVP64.RB))
621 sum[0:(XLEN*2)-1] <- prod + EXTS(SVP64.RC)[0:XLEN*2]
622 SVP64.RT <- sum[0:XLEN-1]
which is how i can convince myself that "the instruction meaning
did not change" - despite being Prefixed.
(will answer about Saturation and Predication in a followup)
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Libre-SOC-ISA