[Libre-soc-isa] [Bug 1062] OPF RFC ls005 iterative feedback and questions

[bugzilla-daemon at libre-soc.org]

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

--- Comment #6 from Paul Mackerras <paulus at ozlabs.org> ---
Given that this document (ls005) explicitly doesn't settle on final wording for
the contentious cases, it is not an RFC, but rather a Formal Proposal.

Overall my opinion is that this would be quite invasive yet not really satisfy
the need to specify what happens with SVP64 vectorization. It expresses the
potentially shorter element width that SVP64 can specify, but doesn't express
doing multiple operations within one register, or the effect of predication, or
possible saturating arithmetic, all of which SVP64 can specify.

Also, with SVP64, the value of XLEN that applies to a given instruction is set
dynamically, whereas there is no obvious way to control XLEN in the other cases
given as justification. Is it a constant of the implementation in those cases?

I also don't think that setting XLEN=32 globally is a good way to describe a
32-bit Power ISA processor, because it (i.e. the current ISA with XLEN set to
32) would be quite incompatible with past 32-bit PowerPC implementations. For
example, instructions like cmpw would only operate on 16 bits rather than 32,
and you'd have to use cmpd to get a 32-bit comparison (which is an illegal
instruction on 32-bit PowerPC CPUs).

It seems that there would be no chance of binary compatibility between an
XLEN=32 implementation and an XLEN=64 implementation. In contrast, you can
successfully run a binary compiled for an older 32-bit PowerPC implementation
on a CPU that conforms to PowerISA v3.1B (at least as far as user-level
instructions go).

How do loads and stores work? Does XLEN=32 mean they do half width, or are they
exempt? If they only do half width, then they would only load or store half the
amount of data that programmers would expect from the mnemonic. For example, an
lwz instruction would load 16 bits, an lhz would load 8 bits, and I don't know
what an lbz would do. That would be quite confusing.

Regarding the notion of grouping registers to get an address, when the size of
an address is larger than the size of a register, does that apply to SPRs too?
Do SPRs change size according to XLEN? If so, do we then need multiple SPRs for
things like the PTCR?

In general, having instructions with "d" for "doubleword" in their name only do
32 (or 16 or 8) bits would be very confusing for programmers (and similarly for
"word" and "halfword").

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