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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed May 13 09:17:20 BST 2020


On Wed, May 13, 2020 at 3:57 AM Jacob Lifshay <programmerjake at 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.



More information about the libre-riscv-dev mailing list