[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 #24 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Luke Kenneth Casson Leighton from comment #12)
> (In reply to Paul Mackerras from comment #5)
> > "SVP64 encoding features" section:
> >
> > At this point, what readers need to understand is the following:
> > 
> > * SVP64 instructions are always prefixed (64 bit) instructions.
> 
> there aren't any SVP64 instructions. there *really is* only
> "32-bit Prefix followed by any Scalar 32-bit instruction".

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
CPU. 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.

[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.]

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). But
it sounds like that is not true, unfortunately.

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