[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 #109 from Alexandre Oliva <oliva at gnu.org> ---
/me blinks, blinded by the light that just hit him

yeah, now it all makes sense.  I found it so hard to believe that the 16-bit
immediate insns were limited to such narrow immediate fields that I managed to
twist 16bit/imm into 16+16.  I wanted it so bad that I made it so.  *blush* 
wow, what a mess I have made!  apologies for being so dense, and for the noise.

I (think I) get it now.  compressed mode is 16-bit to enter (called 10-bit,
because 6 bits are used by the opcode that tells us it's a 16-bit insn we're
lookng at, rather than the usual 32-bit), and 16-bit only while in compressed
mode.  now, some of the 16-bit insns may only switch back to 32-bit mode
permanently, while others can also switch for one insn (N is not repurposed),
and some can't switch out at all (M is repurposed)

this means the logic in the compression estimator I wrote on Saturday is all
wrong.  dang!


ok, I went through it all again, under this new understanding, and though it's
almost as if I was looking at a fully rewritten document, it all makes a new
sense to me ;-)

new questions pop up:

- what's the use of N, when M is not there, as in the "16-bit mode only" blocks
of encodings under 2.1.7 Logical and 2.1.8 Floating Point insns?

- "SV Prefix over-rides help provide alternative bitwidths for LD/ST" -> I had
previously assumed this was an instruction prefix, a little bit like the
extend-next-insn opcode I'd suggested before.  Now, I assume it's not.  how
does that work, then?  I suppose I may have to know it, to estimate correctly
the compression of these instructions.

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