[Libre-soc-dev] Compressed instructions (was: Re: [libre-soc-dev] Alex Oliva's intro, and RFC on mission)

Cole Poirier colepoirier at gmail.com
Sat Nov 21 07:27:13 GMT 2020

On Friday, November 20, 2020, Alexandre Oliva <oliva at gnu.org> wrote:

> On Nov 20, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> > jumping straight into practical matters: we're in the middle of
> > getting SimpleV redone on top of OpenPOWER, and a first step there is
> > Compressed Instructions.
> So, if I understand what I read in bug 238, we are looking into
> introducing an extension to PowerISA for code compactness, a little like
> Thumb vs ARM, with 16-bit instructions rather than 32-bit ones, so that
> fragments of code that fit certain constraints, such as using only a
> subset of the register file, sufficiently-narrow immediate operands and
> offsets, and a limited set of operations, can be represented in such
> shorter instructions, so as to save instruction cache, memory, bus
> traffic, etc.

Hi Alexandre, I’m by far the least experienced and technically literate
member of the project, but if I’m understanding correctly I think that the
idea is to do the opposite of ARM vs thumb. The op codes in the compressed
ISA extension will simply be duplicate versions of ones that exist in the
3.0B version of the OpenPowerISA, and that the 16 bit instructions will be
in the same stream and addresses as the 32 bit standard ones. There will be
one instruction to indicate entrance into 16 bit instruction mode, one to
exit back to normal 32 bit mode, one to execute *only* the next instruction
in 32 but mode then return to 16 bit mode (I believe this is useful for
larger immediates(?)), and perhaps there is a use case for having a 32 bit
instruction that executed only the next instruction in 16 bit mode then
resuming 32 bit mode execution but that seems to not make much sense to me.
I’m sure I’ve gotten something wrong here, I’m a noob, but I’m sure Luke,
Jacob, or Lauri will correct it tomorrow. Hopefully I’ve understood enough
to correctly explain at least something.

Also, I think that unfortunately a large portion of this discussion
occurred on this bug https://bugs.libre-soc.org/show_bug.cgi?id=213 before
Luke realized that it was better suited to this bug than the main SimpleV

Glad to have you with us, especially with your commitment to Libre
principles, and your extensive knowledge of and experience with GCC and


More information about the Libre-soc-dev mailing list