[PATCH v3 1/8] riscv: Avoid unaligned access when relocating modules
Emil Renner Berthing
emil.renner.berthing at gmail.com
Mon Feb 28 04:46:00 PST 2022
On Mon, 28 Feb 2022 at 01:45, Samuel Bronson <naesten at gmail.com> wrote:
>
> Emil Renner Berthing <kernel at esmil.dk> writes:
>
> > With the C-extension regular 32bit instructions are not
> > necessarily aligned on 4-byte boundaries. RISC-V instructions
> > are in fact an ordered list of 16bit native-endian
> > "parcels", so access the instruction as such.
>
> Hold on a minute, this is what it says in my copy of the Unprivileged
> ISA:
>
> ,----
> | RISC-V base ISAs have either little-endian or big-endian memory systems,
> | with the privileged architecture further defining bi-endian operation.
> | Instructions are stored in memory as a sequence of 16-bit *little-endian*
> | parcels, regardless of memory system endianness. Parcels forming one
> | instruction are stored at increasing halfword addresses, with the
> | *lowest-addressed parcel holding the lowest-numbered bits* in the
> | instruction specification.
> `----
> [Emphasis mine.]
>
> In other words, the parcels are little endian, and they're arranged in
> little-endian order. System endianness doesn't matter, it collapses to
> plain old little-endian.
Wow, this actually changed since I wrote this code, nice catch. In
specs up until the latest it used to say "Instructions are stored in
memory with each 16-bit parcel
stored in a memory halfword according to the implementation’s natural
endianness". I hope noone designed a big-endian core before they
changed it.
> (I'm really not sure why they describe the ordering in such a
> round-about way; I assume that's the source of the confusion here?)
I guess the round-about way is exactly because the parcels used to be
native-endian, but the order of the parcels alsways little-endian.
/Emil
More information about the linux-riscv
mailing list