[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 #90 from Alexandre Oliva <oliva at gnu.org> ---
Here's a potential conflict, and another opportunity for an escape encoding for
future extensions, that just occurred to me while getting my brains fried :-)
trying to figure out how to decide the best way to compress each insn as it
goes by, with zero look-ahead:

if we are in 16-bit mode and encode an insn that switches to 32-bit for one
insn, and then we find a 10-bit insn, we could:

- rule that out, since it could have been encoded as a 16-bit insn (every
10-bit one can, right?)

- accept it, but require the 10-bit insn to state the next insn is to be in
16-bit mode, so as to agree with the 1-insn switch from the previous 16-bit
insn

- accept it, and specify which of the settings prevails


Another occurrence we may want to ponder whether to allow is a pair of adjacent
10-bit insns, the first of them saying the next insn is a 32-bit one.  Though a
10-bit insn can be encountered whenever a 32-bit insn is expected, tt makes
very little sense, if my assumption is correct that every 10-bit insn can also
be encoded as 16-bit.  We might get some simplifications (and opportunities for
future extensions) by ruling such pairs (or long sequences) out.

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