[Libre-soc-isa] [Bug 529] scheme for supporting 16/48-bit instructions on PowerPC LE with full backward compatibility

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=529

Alexandre Oliva <oliva at gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oliva at gnu.org

--- Comment #9 from Alexandre Oliva <oliva at gnu.org> ---
I can't help the feeling that we're wasting precious encoding bits to remain in
16-bit mode.  We could easily double the number of accessible registers using
them, and having an encoding similar to that of nop to switch out.

I'm also thinking that, if we use 6 bits just to enter 16-bit mode, and the
remaining 10 bits, though theoretically useful, will most often go to waste,
and we were willing to spend 2 bits to remain in it, we might as well use
one-byte nops (suitably encoded) to switch between modes, and have 16-bit
instructions using the whole 16 bits.  We could then have 16-bit instructions
starting at odd addresses, and 32-bit ones at even addresses, sort of like
ARM/Thumb, SH5media/SHcompact, etc, but for real.

(I realize this would make every other instruction cross a word boundary; we
don't seem to have ruled out doing so for 32-bit insns, so I assume we have
figured out how to save part of one word used for one insn, to use along with
part of the next word that holds the other half of the insn)

We could have an even more extensive opcode selection by giving up 3-register
encodings, and follow the practice of other compact encodings of using a single
register as input and output operand.  Most (*) 3-operands insns x := y op z
can be turned into x := y ; x op= z, which is no worse and probably better than
switching to 32-bit mode, and we could have an extend-next pseudo-insn to
supply an extra operand and/or extra immediate/offset bits to the subsequent
insn.

(*) the exception being x <- y op x, when op is not commutative

With the even/odd address distinction, we could have code labels, even function
entry points, at odd addresses.  Relative branches in 32-bit mode wouldn't be
able to reach them, but for those, we could just insert a nop across the label:

  <32-bit conditional branch to L>
  <32-bit insn>
  < 8-bit switch to 16-bit mode>
  <16-bit insn>
  < 8-bit first half of 16-bit nop>
L:
  < 8-bit second half of 16-bit nop, AKA 8-bit switch to 16-bit mode>
  <16-bit insn>
  <16-bit insn>
  <32-bit 16-bit extend-next + 16-bit extended insn>
  ...

Should I develop these possibilities further?

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