[Libre-soc-dev] Compressed instructions

[Jacob Lifshay]

On Sun, Nov 22, 2020, 10:04 Alexandre Oliva <oliva at gnu.org> wrote:

> Hello, Cole,
>
> Thanks for the info and for the appreciation.
>
> I finally had a click last night, in which the 10-bit encoding I kept
> hearing about but couldn't find documented anywhere made sense was the
> very insn that switched to 16-bit mode, rather than something entirely
> different that I couldn't tell whether was preexisting or something else
> we were working on.  Now I think I have a solid picture.  We may have:
>
>   <32-bit insn>
>   <10-bit insn>
>   <16-bit insn>
>   <more 16-bit insns>
>   <16-bit insn with bits to switch back to 32-bit mode>
>   <32-bit insn>
>

You can also have:
<32-bit insn>
<10-bit insn>
<16-bit insn with bits to switch back to 32-bit mode>
<32-bit insn>

or

<32-bit insn>
<10-bit insn>
<16-bit insn with bits to switch back to 32-bit mode but only for 1
instruction>
<32-bit insn>
<16-bit insn with bits to switch back to 32-bit mode>
<32-bit insn>

which saves just a few bytes and will be common in code sequences with lots
of instructions that aren't supported in compressed mode.

This means we do have the problem of, by just looking at the bits at a
> certain location, not knowing how it ought to be decoded.  That may be
> trouble for the disassembler, but given we spend 6 bits just for the
> mode-switch, I very much doubt it would be viable and wise to make pairs
> of 16-bit instructions immediately recognizable as such, rather than as
> a single 32-bit instruction, by their encoding.
>

The current plan is to have all branch/call/return destinations start in
32-bit mode and be aligned to 32-bits because Power requires branch
instructions to mask-off the 2 least significant bits, allowing programmers
to keep whatever garbage they like there. The only instructions that
support branching to 16-bit mode is interrupt/exception return
instructions, since preemptively context-switching a program currently in
16-bit mode needs to not break it. We can assume that the Linux Kernel
doesn't keep garbage in the saved instruction pointer.

Jacob

>