[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 #143 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #140)

feeling better, had some food.

> this is not the case of the extsb insn I quoted:
> 
> | N | 1 |  RT | | 100.0 | RB  | 0 0 0 | 0 | extsb
> 
> see the N there at bit 0?  I do.
> 
> see M there at bit 15?  I don't.  I see that fixed at 0.

ok.  i realised with some thought tgat i think i have a way to explain it.

1)

when you see an N or an M in any given row it means, "ignore this bit
completely abd utterly,  because the Phase 1 decoder algorithm has already used
it (N or M) to determine the length+mode".


2)

when you see a 1 or a 0 in the N or M positions, it means, "as part of the
PHASE TWO decoder process, please take these bits into account as part of the
**OPCODE** identification process"

one example of such is:

* N=1 & M=1 & Cmaj.m!=0b001.1 => the opcodes are translated according to the
"immediates" section.

now, i am looking at bit 15 of this

 | N | 1 |  RT | | 100.0 | RB  | 0 0 0 | 0 | extsb

and am wondering, myself, why on earth it is set to 0 rather than M.

i will have to do a full examination of the entire encoding table to work out
why, and get back to you.
sigh.

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