[Libre-soc-dev] Compressed instructions

[Luke Kenneth Casson Leighton]

On 11/23/20, Alexandre Oliva <oliva at gnu.org> wrote:

> It doens't work in a standalone disassembler, or even in a binary
> translator (say qemu):

it has to (and does).  the same rules apply: qemu must, at the point
of decoding the instruction, take into account the current Machine
state.

i know that it does so because it is capable of executing the
canonical "startup" code which swaps the MSR (Machine Status Register)
LE/BE mode to a known-good (required) state.

this is a neat trick where the instruction 0x48 00 00 08 (it might be
0x48000024) is a branch in one mode and a trap (maybe a branch to
another location) in the other.

if qemu is not capable of executing that code which changes MSR and
alters every subsequent insteuction then unlike disassemblers which
are simply offline debugging tools that is a severe (catastrophic) bug
in qemu.

> That sucks, but what I get from you is that that's how ppc already is,
> at least to some extent.

yes, and the intention is to crank it up an order of magnitude.

SV Prefixing adds Vector Context around scalar instructions.  this
again requires state (enough so that a new SPR or two are needed to be
saved alongside the PC and MSR on a context switch).


> I'm on board with that.  However, there are things we can do to
> alleviate it, and to enable us to have functional tools.  See below.

ack.


> Indeed, it's not an issue for userland disassemblers.  It wouldn't be
> possible for disassemblers to deal with it without actually simulating
> all potential paths in the program to tell what the status register bit
> looks like when a specific code address is reached.

i may be naively expecting functions to be single entrypoints,
selfcontained and thus with the hard rule "no state allowed except
v3.0B standard mode" at entry and exit i would not expect problems.

except on static highly optimised leaf node code where the ABI rules
have been (safely) disregarded.

>> if the hard rule is set that a function call may only be entered and
>> exited in standard v3.0B Mode to respect standard ABI the problem is
>> 99.9% solved.
>
> It surely helps, but in general you don't want to have to disassemble
> and interpret all paths within a function to tell the execution mode
> that will be active when you reach a certain location you want to
> disassemble.

tck.. tck.. *thinks*... argh execution order is not the same as
listing order, is it?

nuts.


> A non-loadable section encoding compressed mode code ranges would be a
> great help to disassemblers.  The assembler could create it
> transparently, whether it performs the compression itself or takes
> directions from the compiler.

yeah i like that idea a lot.  neat solution.

> I think it would be wise to make something like this part of the design
> and implementation of our extensions based on dynamically-changeable
> modes.

yes, very much so.

>> this just leaves raw assembly to sort out and for that there is
>> commandline switches (LE/BE, 32/64 being existing examples of such).
>
> Those combinations usually live in different object file formats, so the
> "status bits" that aid in decoding are a given.

iiinteresting.  and extending that is therefore not such a stretch.  nice.

l.