[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 #74 from Alexandre Oliva <oliva at gnu.org> ---
re: comment 72

going 2-operand to have access to the entire register file doesn't change the
nature of the direct mapping at all.  when I speak of expanding the scope of
the compressed isa into a fuller isa, I'm not talking of inventing new insns
not present in 3.0B, nor borrowing insns from Thumb proper, I'm talking of
getting more coverage of 3.0B insns.

e.g. 8 registers would to too little even if r0, r1 and r2 weren't reserved to
begin with.  it's a bit like going back to 32-bit x86, but with plenty of
registers there, just not as usable because we're wasting representation bits
with something else, so they require switching to uncompressed mode which we'd
rather not do.

as for multi-issue, having encoding bits in every insn to tell how the very
next one is to be interpreted doesn't help much with that.  mode transitions
had better be the exception rather than the rule.

OTOH, I can hardly tell the complexity difference between one bit that says
"return to compressed mode after the next 32-bit insn" and one that says "use
this register as the first input operand instead of the output one in the next
insn".  that's just a selector in the mapper, that would otherwise merely
duplicate the output register.

it's one bit that affects decoding of a subsequent instruction one way or
another.  but by avoiding this escaping, we instead force the more frequent use
of another escaping mechanism, namely switching to uncompressed mode.  it's
just that with this one, we ensure that *every* occurrence of a 3-operand insn
(among the selected opcodes) can be represented in 2-operand compressed mode,
even those that can't be made up for with a register-copy insn.

also consider that, unless I'm missing something about the ppc encoding, using
the full 16 bits and 2 5-bit operands makes the mapping much easier: 6 bits for
the EXT opcode, plus the 2 operands makes 16; in many cases, the mapping could
just directly copy 11 bits directly, without any mapping whatsoever; the
intelligence would have to go into where/how to copy the remaining bits, and in
whether to duplicate the first operand into one of the input fields.

is that not much much simpler, efficient and likely to be accepted than not
just one, but two new encodings?  (namely 10- and 14-bit AKA 16-bit?)

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