Endianness and instruction encoding

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
bandrami
Posts: 2
Joined: Fri Feb 13, 2015 12:25 am
Location: Mumbai

Endianness and instruction encoding

Post by bandrami »

Hi all, long time lurker. I'm mucking around with a OS-less FORTH for ARM. While making the internal assembler I started playing around with ARM's variable endianness (call it perversity on my part) and I'm getting stuck conceptually here. The chip manual says that the endianness settings "do not affect instruction fetches" and that "the mapping of instruction memory is always little-endian", but it's not clear to me what that means exactly.

To take an simple instruction example, BKPT (breakpoint) is 11100001001000000000000001110000. Now, as an instruction/bit pattern, that doesn't really have any "endian-ness" to speak of (endianness being how you interpret a word as an integer, and an instruction isn't interpreting a word as an integer -- the intra-instruction "immediate number" formats are all defined already). (Also, I know the Thumb instruction set is a weird half-word invariant setup, but I'm not using T or TEE so we can ignore it for now.)

So, if for whatever reason I had to write a BKPT instruction byte by byte starting at A, is the point that I would need to write

01110000 at A
00000000 at A + 1
00100000 at A + 2
11100001 at A + 3?

And that if I stored 0b11100001001000000000000001110000 or 0xE1200070 at A in the little-endian regime it will "just work", whereas if I'm big-endian at the time of the store I will need to byte-reverse the word (so that I would literally be writing 0x700020E1?)
Old Forth Geezer. I miss the 1980s, when your computer was simple enough to understand
User avatar
thepowersgang
Member
Member
Posts: 734
Joined: Tue Dec 25, 2007 6:03 am
Libera.chat IRC: thePowersGang
Location: Perth, Western Australia
Contact:

Re: Endianness and instruction encoding

Post by thepowersgang »

That sounds as I would expect it.

If the data accesses are BE, but the instruction fetches LE, then you'd have to endian flip the instruction when you write it out (assuming you're constructing them yourself, and not just copying from elsewhere in memory).
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
alexfru
Member
Member
Posts: 1112
Joined: Tue Mar 04, 2014 5:27 am

Re: Endianness and instruction encoding

Post by alexfru »

It all most likely means that the values that you load from memory or store to memory using the dedicated load/store instructions are affected by the endianness selection, while the immediate operands of instructions (the ones embedded in instructions) aren't affected and always have the same representation (i.e. the least significant bit of an immediate operand has the same fixed bit location within the instruction).
embryo

Re: Endianness and instruction encoding

Post by embryo »

bandrami wrote:The chip manual says that the endianness settings "do not affect instruction fetches" and that "the mapping of instruction memory is always little-endian", but it's not clear to me what that means exactly.
It means that any part of an instruction, that has more than one byte, is interpreted in a way that is called "little endian". And because of such (and only such) interpretation nothing can change the order of instruction bytes, that is expected by a processor.
Post Reply