[Libre-soc-dev] Compressed instructions

[Alexandre Oliva]

On Nov 22, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> this is actually very simple: take the status register and shove a
> copy onto the MSBs of the current instruction being decoded... and
> *then* start decoding.

This works within a debugger, when you have a status register to take
bits from.

It doens't work in a standalone disassembler, or even in a binary
translator (say qemu): the same bits are to be interpreted in different
ways depending on how you get there.

That sucks, but what I get from you is that that's how ppc already is,
at least to some extent.  That's unfortunate IMHO, but that's how it is,
so we might as well take advantage of it.

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.

> this should already be done in binutils for changes to ppc64 MSR that
> alter LE/BE and if it is not then that is quite a bug in binutils
> objdump.  however given that very few programs are likely to do that,
> combined with it being a privileged operation, it's understandable
> that it's never come up.

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.  Quite a challenge
even when you have all the executable code potentially reachable in a
program, which you don't always have, e.g. when you're looking at an
executable but not the dynamic libraries it loads.  I'm pretty sure if
you could do this in the general case you'd have solved the halting
problem too, but I disgress... ;-)

> 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.  Add no-return function calls for ambiguity and non-local
branches for non-locality and it becomes quite an interesting problem.

IOW, our likelihood of having a functional disassembler is pretty low if
we don't make any arrangements whatsoever to annotate labels or code
ranges with their execution modes.

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.

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.

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

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar