[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

[bugzilla-daemon at libre-soc.org]

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

--- Comment #164 from Alexandre Oliva <oliva at gnu.org> ---
it occurred to me that the reversal of M and N might have contributed to our
miscommunication in my question about N without M.

now here's another bit that may be contributing to our miscommunication, and
that it would be good to clear up, if nothing else because it might be hiding a
major problem in the encoding design

I hear that the mode and length decoder, namely phase 1, only have to look at
bits M and N of compressed insns to determine length of current insn and mode
of the next, and that's what's pseudocoded.

me, I see no way to avoid also looking at Cmaj.m bits to tell whether M and N
have the usual meaning, or whether we're looking at a '16b sub' insn, where the
bit that usually holds N serves a different purpose.

I build my case on the following opcodes:

| 0111 | BA2 | | 001.1 | 0 BA | BB  | M | crnand
| 1000 | BA2 | | 001.1 | 0 BA | BB  | M | crand

if the decoder naively looks at the bits usually assigned to N and M, namely 0
and 15, I think it could make decisions that AFAICT would be incorrect for
subsequent insns

my assumption is that, for these insns depicted under 2.1.9, N is absent, so
only M should take effect, as in the 10-bit encoding.  IMHO it would be
surprising, bordering nonsensical, for part of the subopcode to force some of
the cr ops (like crand, whose "N" is 1) to choose between only be followed by
32-bit then 16-bit or remain in 16-bit mode, while others (like crnand, whose
"N" is 0) have to choose between permanent 32- or 16-bit.

now, consider a 16-bit crand insn is to be followed by several uncompressed
insns, so it has M=0

the phase 1 decoder, however, looks at M and N bits and sees NM = 0b10, meaning
32-bit-then-16-bit

so the next insn will be decoded as an uncompressed 32-bit one, just as
expected

but after it, we'll return to compressed mode, which is (to me) not expected

thus I claim the phase 1 decoder has to look at Cmaj.m, in addition to M and N,
to tell that the bit that usually means N doesn't really mean that for that
opcode.

is that really not so, i.e., are cr opcodes really to have their bit 0
interpreted as N even though it's also part of the subopcode?

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