[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 #106 from Alexandre Oliva <oliva at gnu.org> ---
the other head-exploding apparent (?) contradiction is that, if we're planning
to have compressed insns that could have N=M=1 to gain a 16-bit extension, or
other values for N and M to guide the decoding of subsequent insn(s), why,
insns that may take N=M=1, must these extra 16 bits be used exclusively to
encode (extensions of) immediates, and absolutely never to encode register
fields, or extensions of register fields?

the complexity of using 32 bits for a compressed insn is already dealt with
before we even look at those extra 16 bits, they're passed-through to the
second-stage decoder to be remapped into a 32-bit instruction.

why can the bit-shuffling in this decoder/remapper even deal with immediates of
different lenghts, depending on the opcode encoded in the first half-word, and
it can even map registers according to a mapping table, but it can't possibly
deal with additional bits for register fields, or an additional register field,
even one that could be copied straight to the corresponding uncompressed insn,
without any mapping whatsoever, if that's the format (input and output of the
remapper) for the selected opcode?

In both cases, we're going to be rearranging bits from a pair of half-words to
the opcode-dictated 32-bit instruction format.  And yet you seem to react with
a knee-jerk rejection to one, and a grand-fathering of the other, while they
seem entirely equivalent to me.  Can you elaborate on the reasons for the
differences?

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