[Libre-soc-dev] compressed instructions state requirements

[Luke Kenneth Casson Leighton]

On Tue, Nov 24, 2020 at 5:41 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> If the word-swapping scheme is as I described earlier and the only
> instructions used are 32/64-bit 32-bit-aligned instructions, then they are
> indistinguishable since they are the exact same bytes in the exact same
> memory locations (assuming the standard PowerISA LE/BE etc. modes are
> known).

this - 32/64 - i can grok.

> If the stream contains any 16 or 48-bit instructions, you also need
> the twos place in the PC.

are you *certain* that PC[1] is the only information needed?  i'd
really like to see a brute-force-generated table which shows that.
which shouldn't be difficult to generate: 4x for-loops to generate all
possible permutations of 16/32/48/64 bit instructions.

> If the stream contains any 16-bit instructions,
> then you also need to know if the decoder should start in Standard or
> Compressed Mode, and (assuming we include the
> switch-to-standard-mode-for-1-instruction
> bit) if the last instruction specified the
> switch-to-standard-mode-for-1-instruction.

ahh this is what i was expecting.  and it basically means that we are
going to need to, just like VLE, mark 64k pages as
"alternatively-encoded".  given that 32-bit opcodes can be embedded in
that, this is not a big deal.

my former misunderstanding of VLE was that it was exclusively
16-bit-only opcodes: it's not.  it's mixed standard (v2.07B) and
16-bit instructions.  if it was only 16-bit instructions, there would
be a serious problem because you'd need to fill pretty much the
entirety of the 64k page with branches into standard 32-bit
instructions, and back.

if however a mix is permitted within a "marked" 64k page (16/32/48/64) then the


> I renamed 32-bit mode to Standard Mode since it is the backward-compatible
> mode and also supports 64-bit (ISA v3.1)

caveat (1) it's in the future (because of the EULA only granting
permission to do v3.0B)
caveat (2) if designing ISA extensions we still have to take into account v3.1B:

those caveats taken into consideration: i'm very strongly in favour of
not supporting v3.1 prefixing, except under severe arm-twisting
circumstances, and *definitely* as a hard-rule mutually-exclusively
incompatible with *any* SV Prefixing.

however it *MIGHT* and i stress *MIGHT* be ok to interleave v3.1B
instructions with 16-bit Compressed.  but definitely *NOT* with SV
Prefixing.

the reason is very simple: the decoding of the length of an
instruction has to be done through strict top-level analysis without
"deep packet inspection".

> and 48-bit (no spec yet) instructions.

TBD when we get to SV Prefixing.  remember also that we have SV-P64
(32-bit SV prefix plus a 32-bit instruction) and we have SV-C64
(32-bit prefix plus a 16-bit swizzle prefix plus a 16-bit Compressed)

> Compressed Mode is 16-bit only.
>
> >
> > this is a really important non-rhetorical  question that i would
> > appreciate if you could answer plainly yes or no.
> >
>
> so, extra state beyond PowerISA v3.1 is needed:
> the twos place of the PC. (needed for 16 and/or 48-bit instructions)
> the decode mode (Standard/Compressed) -- 1 bit. (only needed for 16-bit
> instructions)
> the last instruction's switch-to-standard-mode-for-1-instruction bit (only
> needed for 16-bit instructions with optional switch-to-standard-mode
> -for-1-instruction).
>
> If we don't mind compressed instructions always having only 10-bits of
> space available, the only extra state required is the twos place of the PC.
> No compressed mode necessary.

this will definitely need to be demonstrated, with a full proof
(covering all possible permutations).

> > ah that looks really good athough it looks like it should be in
> > https://libre-soc.org/openpower/sv/major_opcode_allocation/  (for now)
> >
>
> Maybe, it might be better on its own page --

yes good idea, go for it.

> basically I wrote out all the
> supporting info but never got to writing the actual demo... :P

:)