[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 #105 from Alexandre Oliva <oliva at gnu.org> ---
ok, one or both of us are making some incorrect assumptions.  here are the
facts that come across as inconsistent to me:

1. https://libre-soc.org/openpower/sv/16_bit_compressed/ says, in 2.1: The
current "top" idea for 0b11 is to use it for a new encoding format of
predominantly "immediates-based" 16-bit instructions (branch-conditional, addi,
mulli etc.)
[...]
| 1 | flds | Cmaj.m | fields | 1 | 16b/imm then 16bit

2. the same page says, in 2.1.1:
| 1 | immf | Cmaj.m | fld1     | imm      | 1 | 16b imm


3. and then, in 2.1.2: Immediate Opcodes only available in 16-bit mode, only
available when M=1 and N=1 and when Cmaj.min is not 0b001.1.
| 1 | 0  | 0   0 0 | | 001.0 |      | 000 | 1 | TBD
[...]
| 1 | i2           | | 010.0 | RA!=0| imm | 1 | addi

4. in 2.1.9: Condition Register
| 0 1 1 1 | BA2 | | 001.1 | 0 BA | BB  | M | crnand
| 1 0 0 0 | BA2 | | 001.1 | 0 BA | BB  | M | crand
i.e., there is M, but N seems to be repurposed as part of the extended cr
opcode, so N=M=1 actually encodes a 16-bit insn without a 16-bit immediate


>From that, I conclude that either:

a. addi, in compressed mode, has M=N=1 and therefore is necessarily a
16-bit+16-bit-imm insn, i.e., 16-bit insn formatted as above, followed by a
16-bit immediate, for a total 32 bits, and the CR encoding is an aberration, or

b. addi and other immediates, in compressed mode, repurpose M and N as part of
the opcode, sort of, just like CR insns repurpose N alone, and they are
actually just a 16-bit insn formatted as above, without a 16-bit extension, and
without a possibility of one

now, in either case, we can't just look at M and N to tell the length of an
insn while in compressed mode.  we have to also look at the opcode to tell
whether those bits actually stand for the regular meanings of M and N, or part
of the fixed bit pattern of certain compressed insns.

but then, from your adamant statement that those two bits ought to be enough to
tell the compressed insn length, and even that's barely acceptable, I conclude
it can't be so, and my head explodes ;-)

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