4 ms·

You're correct, but I was unclear. What I find confusing is that there are two concepts in ordering of bits, and they are not "in sync": bytes and words and the

You're correct, but I was unclear. What I find confusing is that there are two concepts in ordering of bits, and they are not "in sync": bytes and words and the order of individual bits. This means there is both "least significant bit" and "least significant byte". # Little Endian Machine 87654321 87 65 43 21 # Big Endian Machine 87654321 21 43 65 87 # Big Endian Machine, word-wise 87654321 12 34 56 78 In a world where endianness concerns only words, there would only be 12345678 and 87654321, but not the word-wise mixing as in 21 43 65 87. I suppose this is because the individual adressable unit of memory is a byte, and byte streams can be interpreted in different ways (as int8, int16 etc)? And because bytes are usually opaque to the programmer into how they lay out their bits internally to represent a uint8? It makes sense, but without a lot of context around it, it is very confusing initially.

vlovich123 5y ago
The bit order within a byte can be thought of as always big endian. In fact you can think of it this way for any multi-byte number (floating point too). The reason is that the CPU takes care of this all for you (because sanity). So what the little endian CPU is doing is saying “read 16 bit 0xcd 0xab from main memory” which results in it storing the number as “0xabcd” in the register. If you said “read 32 bits from 0xcd 0xab 0x00 0x00” from memory the CPU would see “0x0000abcd” This is all internally consistent. However, if you said on your big endian machine “write the 16 bit number 0xabcd to main memory” it would store “0xab 0xcd”. Then you say “write those 16 bits to I/O and OS I/O routines don’t understand the structure you’ve assigned to memory so they just copy that to the wire. This leaves you with “0xab 0xcd” on the wire. Then your little endian machine says “read 16 bytes from the wire” and gets “0xab 0xcd”. But then you’re smart and you go “I was expecting a 16bit number here - cpu read this as a 16 bit number” and the CPU goes “main memory stores little endian 16bit numbers so I see 16 bit number 0xcdab” (because 0xcd is the least significant byte”. The smallest addressable unit of CPUs you encounter is bytes whatever size the CPU vendor chooses that is in terms of bits. So a CPU would never read a little endian or big endian byte because it’s simpler to just pump the bits directly instead of swizzling them (easier to debug, analyze etc). You could design a CPU that stored numbers in bit-order little endian or big endian but you’d basically be incompatible with all software out there and no language provides support for dealing with that because you’d be very niche.

vlovich123 5y ago

The bit order within a byte can be thought of as always big endian. In fact you can think of it this way for any multi-byte number (floating point too). The reason is that the CPU takes care of this all for you (because sanity). So what the little endian CPU is doing is saying “read 16 bit 0xcd 0xab from main memory” which results in it storing the number as “0xabcd” in the register. If you said “read 32 bits from 0xcd 0xab 0x00 0x00” from memory the CPU would see “0x0000abcd” This is all internally consistent. However, if you said on your big endian machine “write the 16 bit number 0xabcd to main memory” it would store “0xab 0xcd”. Then you say “write those 16 bits to I/O and OS I/O routines don’t understand the structure you’ve assigned to memory so they just copy that to the wire. This leaves you with “0xab 0xcd” on the wire. Then your little endian machine says “read 16 bytes from the wire” and gets “0xab 0xcd”. But then you’re smart and you go “I was expecting a 16bit number here - cpu read this as a 16 bit number” and the CPU goes “main memory stores little endian 16bit numbers so I see 16 bit number 0xcdab” (because 0xcd is the least significant byte”. The smallest addressable unit of CPUs you encounter is bytes whatever size the CPU vendor chooses that is in terms of bits. So a CPU would never read a little endian or big endian byte because it’s simpler to just pump the bits directly instead of swizzling them (easier to debug, analyze etc). You could design a CPU that stored numbers in bit-order little endian or big endian but you’d basically be incompatible with all software out there and no language provides support for dealing with that because you’d be very niche.