[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 #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
erroneous.


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
   else
        next = std.32
if prev == C.16bit:
    if insn[0] == 1 and insn[15] == 1
        DECODE 16 BITS AS C.16.immediate
        CRITICAL NOTE, LENGTH IS 16 BITS
        NOT REPEAT NOT 32
    elif insn[15] == 0
        next = std.32.oneonly
    elif insn[0] == 1 and C.Maj == 0b010
        DECODE 16 BITS AS ALTERNATE
        STUFF
        LENGRH IS STILL 16 BIT

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.

again.

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.