[libre-riscv-dev] more compatible alternative to BE instructions on LE processor

[libre-riscv-dev] more compatible alternative to BE instructions on LE processor

[Jacob Lifshay]

Since having the instruction stream be BE is not directly compatible with
existing LE instructions since calling between them requires a mode switch
to switch endian, I propose a different solution that doesn't require any
mode switch, is compatible with LE instructions, and allows supporting
instructions that are any size, though will probably be limited to
multiples of 16 bits.

My idea is to switch the logical order that instructions are decoded such
that decoding 32-bit LE words starts with the most-significant byte which
contains the opcode, instead of the least-significant byte.

PC would effectively be split into two fields, where the top N-2 bits are
the address like usual, but the bottom 2 bits instead address memory in
reversed order:

PC value -> memory address
0x1000 -> 0x1003
0x1001 -> 0x1002
0x1002 -> 0x1001
0x1003 -> 0x1000
0x1004 -> 0x1007
0x1005 -> 0x1006
0x1006 -> 0x1005
0x1007 -> 0x1004
0x1008 -> 0x100B
0x1009 -> 0x100A
0x100A -> 0x1009
0x100B -> 0x1008
0x100C -> 0x100F
0x100D -> 0x100E
0x100E -> 0x100D
0x100F -> 0x100C
0x1010 -> 0x1013

Since all currently existing Power instructions are a multiple of 32 bits,
this wouldn't change how they are decoded or executed, however, would
change how new 16 or 48-bit instructions are laid out.

If the processor is switched to BE mode (for both instructions and data),
this address reordering would be disabled, since BE mode already has the
opcode byte as the first byte anyway.

(PDP endian resurrected -- sort of)

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] more compatible alternative to BE instructions on LE processor

[Lauri Kasanen]

On Tue, 12 May 2020 19:56:45 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

> Since having the instruction stream be BE is not directly compatible with
> existing LE instructions since calling between them requires a mode switch
> to switch endian, I propose a different solution that doesn't require any
> mode switch, is compatible with LE instructions, and allows supporting
> instructions that are any size, though will probably be limited to
> multiples of 16 bits.

The PowerISA 3.1 doc adds a 32-bit prefix (page 46 of the pdf (reader),
page 22 of the official naming). I didn't go into details, but for such
plans it'd be good to take into account.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] more compatible alternative to BE instructions on LE processor

[Luke Kenneth Casson Leighton]

On Wed, May 13, 2020 at 7:29 AM Lauri Kasanen <cand@gmx.com> wrote:

> The PowerISA 3.1 doc adds a 32-bit prefix (page 46 of the pdf (reader),
> page 22 of the official naming). I didn't go into details, but for such
> plans it'd be good to take into account.

ok that entire section covers a new (extended, 64-bit) instruction
format, including new extended immediates, vector-masks and so on.

it uses major opcode 0b0000001 to do so.

however unlike what we propose (and, crucially, propose to put behind
a mode-switch bit):

* the scheme critically depends on the instructions being chunked into
32-bit sections
* 48-bit and 16-bit instruction encodings are impossible
* we need far more bits (11 bits for C, 11 bits for SVP P48 and 27
bits for SVP P64) than can fit after *one* major opcode.

16 (prefix) minus 6 (major opcode) is 10.  that is not enough to fit
11 bits of SVP P48.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] more compatible alternative to BE instructions on LE processor

[Luke Kenneth Casson Leighton]

On Wed, May 13, 2020 at 3:57 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> PC value -> memory address
> 0x1000 -> 0x1003
> 0x1001 -> 0x1002
> 0x1002 -> 0x1001
> 0x1003 -> 0x1000

NNxx -> NN(3-xx)

> Since all currently existing Power instructions are a multiple of 32 bits,
> this wouldn't change how they are decoded or executed, however, would
> change how new 16 or 48-bit instructions are laid out.
>
> If the processor is switched to BE mode (for both instructions and data),
> this address reordering would be disabled, since BE mode already has the
> opcode byte as the first byte anyway.
>
> (PDP endian resurrected -- sort of)

:)

ok it's effectively "BE instruction order" as separate from "BE data
order".  it's reordering the instruction memory area in a fixed
(non-dynamic) way.

i have a sneaking suspicion jacob that SVP-48 and C (16) will not
interact well with that.  it'll need thinking through, what happens
when there are:

* two C (16) instructions in sequence starting on a 32-bit boundary
* one C (16) instruction followed by a SVP-48, the C (16-bit) starting
on a 32-bit boundary
* a SVP-48 (starting on a 32-bit boundary) followed by a C (16-bit)
* two SVP-48 instructions (starting on a 32-bit boundary)

also necessary to consider how to ensure that "padding" back to 32-bit
boundaries is not misinterpreted as garbage instructions, usually this
by having a 16-bit "NOP" (C) encoding

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev