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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Nov 30 03:19:04 GMT 2020


--- Comment #108 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #105)

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

where the length is, and always has been, including the bits of the immediate,
16 bits total and 16 bits only.

> 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, 

if this was the case, i would have illustrated it with a clear diagram, showing
a total of 32 bits.

also i would have put, "this is a total of 32 bits"

also i would have said, "this is identical to the 32 bit VLE encoding".

none of those things are said, therefore logically we conclude that (a) is

the reasons as twofold:

1) if you are going to have a 32 bit encoding that includes 16 bit immediate,
you might as well use...  the standard v3.0B mode

2) the complexity of mixing phase 1 and phase two is far too great.

even reason (1) is enough to permanently and irrevocable eliminate 16+16
encoding from all consideration.

> 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

this is correct.

> now, in either case, we can't just look at M and N to tell the length of an
> insn while in compressed mode. 

this is incorrect.  the length is 16bit, period.

now, it happens to be the case that at rhe start of the length/mode FSM, when
the 16 bits contains an EXTNNN you IGNORE the 1st 5 bits (the remainder being a
10bit encoding) but that does not change the fact that it is still 16 bits.

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

no, you look at the 2 bits as part of the length/mode FSM.

once you have the mode, the meaning of M and N switches to one of 3 sub-modes,
these are:

* 10bit mode (ignore EXTNNN bits)
* 16bit mode
* 16bit.immed mode

again: repeat again.  repeat again: *all of these are exactly 16 bits*.

repeat again: all are 16 bits.

not 16+16.

not 10.

not 32

16 and 16 only.

> but then, from your adamant statement that those two bits ought to be enough
> to tell the compressed insn length,

when in Compressed mode, the length is 16 bits.  period.

decoding of those 16 bits requires the FSM 

roughly as follows:

prev=std.32 # start of FSM
insn = insnbitstream[0..15] # ONLY 16 bits
                            # NEVER 32

if prev == std.32:
   if insn[EXTBITS] == Compressed
        next = C.10bit
if prev == C.10bit:
   if insn[15] == 1:
        next = C.16bit
        next = std.32
if prev == C.16bit:
    if insn[0] == 1 and insn[15] == 1
        DECODE 16 BITS AS C.16.immediate
        NOT REPEAT NOT 32
    elif insn[15] == 0
        next = std.32.oneonly
    elif insn[0] == 1 and C.Maj == 0b010

current = next

something like that.  it is late so i have not checked the page, some of those
may be ==0 not =1 for bit 0 / 15.

the **ONLY** time that the length is not 16 bit in Compressed mode is when the
**NEXT** instruction is a Standard v3.0B encoding.

i.e. when LEAVING the Compressed mode entirely.


to repeat.

length is ONLY ever 16 bit in Compressed mode.

length is NEVER 32 bit in Compressed mode.

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

More information about the libre-soc-bugs mailing list