[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 #112 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Alexandre Oliva from comment #109)
> /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)

For what it’s worth, I just reviewEd the 16b compressed encoding page and I can
definitely see how Alexandre came to the operating paradigm i.e. set of axioms
interpreted from the wiki page, that he was operating under until this comment.
I find the current diagrams and explanations on the page very confusing,
especially because the discussion of C16 does also discuss SV prefix at points.
Noticing that this will be the 110th comment on this bug report, may I suggest
we open a new bug report entitled “Editing and reorganizing  16 bit compressed
encoding proposal for greater clarity”? I think all of the necessary
information is there, however, it can be presented in with a small amount of
reorganization and editing to be immediately smacks-you-in-the-forehead
obvious, instead of rather difficult, easy to misunderstand/misinterpret, and
confusing.

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