[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 #57 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #56)
> [moved from bug #529] aoliva wrote:
> 
> 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.

this was discussed in comment #8

> 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.

this would require complex scheduling and sizing of instructions to get the
perfect alignment.

of course the imperfect version would simply throw in nops.

if we knew in advance that instruction streams were to remain in 16bit mode
consistently for considerable durations i would be much more in favour of
schemes that had to rely on nops to transition between modes.



> (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,

yep not a problem as long as 32 bit instruction branches are thought through
(v3.0B requires ignoring the bottom 2 bits of the PC)

> 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)

yep, just a queue data structure that can hold at least 48 bits.


> We could have an even more extensive opcode selection by giving up
> 3-register encodings, 

maybe.  bear in mind the idea is to encode the most common instructions.  this
is where we really need that statistical analysis.

> and follow the practice of other compact encodings of
> using a single register as input and output operand. 

this was discussed in comment #18

> 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,

except: look at the amount of space used to do so.  it's still 32 bit, isn't
it?

which means, it's "par" (no advantage eitther way)

and that puts a 16-bit instruction which has 2 src 1 dest at a significant
advantage.

bear in mind: i recognise that on the transition from v3.0B to 16bit mode it's
impossible to fit 3 operands, hence all 10bit encodings are 1 src 1 dest.


> and we could have an
> extend-next pseudo-insn to supply an extra operand and/or extra
> immediate/offset bits to the subsequent insn.

i very much do not want to go down this particular route, although it is very
tempting to do so.

the problem is that it is basically the design route taken by CISC ISAs.  the
extend sequence never ends once the door is opened up, and the encoding FSM
becomes a nightmare (particularly given that we have SV Prefixing to also add)

i would greatly prefer that whatever we cannot fit into 16 bit we simply drop
back into v3.0B compatibility.

remember that proposals for ISA Extensions have to be reviewed by the OpenPOWER
Foundation.  the probability of acceptance is a product of two factors:

* complexity
* benefit

if the complexity is high then the benefit had better be waay higher.


> (*) 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>
>   ...

ahh... ahh... this is novel.  effectively it's using the bottom 2 bits
(actually, bit 1) to indicate the 16/32 bit mode.

that needs some exploration.

> Should I develop these possibilities further?

yes definitely

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