4 ms·

Big-endian is how we write each byte in a hex editor, and so big-endian should be more intuitive. If we have the number 0xDEADBEEF and view it in a memory dump,

Big-endian is how we write each byte in a hex editor, and so big-endian should be more intuitive. If we have the number 0xDEADBEEF and view it in a memory dump, a big-endian system gives: DEADBEEF And a little-endian system gives: FEBEADDE Only one of those reads naturally. As long as your increasing memory order goes from left to right, as is the norm.

AnIdiotOnTheNet 5y ago
> FEBEADDE 0xDEADBEFE?
recursive 5y ago
Any significance to `BE`? It's the only byte that remains untouched.
api 5y ago
Little-endian is superior at the system level largely because casts between integer sizes are free. Casting a 32-bit LE value to an 8-bit value is just reinterpreting what the pointer means. This is a fairly common operation. Big-endian is pretty much dead. I am not aware of any BE systems on sale right now outside small MIPS routers and embedded. If the Internet were designed today network byte order would probably be little-endian. New cryptographic algorithms are being designed little-endian-first.
- swiley 5y ago
  It also hides errors that come from casting between different pointers types.
  - api 5y ago
    That's the job of the language/compiler. Rust does a fine job of this.
- classichasclass 5y ago
  OpenPOWER systems (POWER8 and up) swing both ways. That said, my POWER9 Raptor Talos II runs little endian, though it is completely capable of running big (and at the low OPAL level in fact does), and some operating systems on it support that.
zepearl 5y ago
This might be the most stupid question of 2021, anyway, here it is: but in little-endian systems the order of the individual bits in a byte is still (kind of) big-endian, with the most meaningful bit on the left, right? Personally I always think first about how the single bits are stored in a byte, which is as far as I know, with the most important bit on the left, independently if the system is big- or little-endian, for example: === 0: 0000 0000 1: 0000 0001 2: 0000 0010 ... 255: 1111 1111 === Therefore if the number/value gets bigger than a byte for me it's just more natural to keep adding bits to the left of the sequence of bits (therefore big-endian style), for example: === 256: 1 0000 0000 257: 1 0000 0001 ... ===
- ghusbands 5y ago
  That amounts to the same question - the way we write binary numbers is the same way we write hexadecimal numbers, decimal numbers or numbers in any base; we start with the most significant. This makes the natural form for LTR languages big-endian. It has no bearing on the layout of bits in the RAM chips, caches, register files or data/address lines in a computer. Endianness pretty much only affects the operation of transferring values from/to memory.
  - zepearl 5y ago
    Well, I can change the way I think/do stuff (I can write "1234" or "4321", no problem) but what I meant was basically "for me to make sense, byte-endianness should be aligned to bit-endianness"... . To me it would make sense to use little-endian if the same would be applied as well on the level of "bits" within a byte... . Using little-endian on a byte-level but big-endian on a bit-level (within a byte) is quite confusing for me. Just my subjective opinion.
- yakubin 5y ago
  > but in little-endian systems the order of the individual bits in a byte is still (kind of) big-endian, with the most meaningful bit on the left, right? Single bits are not addressable, so from the point of view of a programmer "order of bits" isn't well-defined. There isn't a way to distinguish endianness of bits for a programmer.

AnIdiotOnTheNet 5y ago

> FEBEADDE 0xDEADBEFE?

recursive 5y ago

Any significance to `BE`? It's the only byte that remains untouched.

api 5y ago

Little-endian is superior at the system level largely because casts between integer sizes are free. Casting a 32-bit LE value to an 8-bit value is just reinterpreting what the pointer means. This is a fairly common operation. Big-endian is pretty much dead. I am not aware of any BE systems on sale right now outside small MIPS routers and embedded. If the Internet were designed today network byte order would probably be little-endian. New cryptographic algorithms are being designed little-endian-first.

swiley 5y ago
It also hides errors that come from casting between different pointers types.
- api 5y ago
  That's the job of the language/compiler. Rust does a fine job of this.
classichasclass 5y ago
OpenPOWER systems (POWER8 and up) swing both ways. That said, my POWER9 Raptor Talos II runs little endian, though it is completely capable of running big (and at the low OPAL level in fact does), and some operating systems on it support that.

zepearl 5y ago

This might be the most stupid question of 2021, anyway, here it is: but in little-endian systems the order of the individual bits in a byte is still (kind of) big-endian, with the most meaningful bit on the left, right? Personally I always think first about how the single bits are stored in a byte, which is as far as I know, with the most important bit on the left, independently if the system is big- or little-endian, for example: === 0: 0000 0000 1: 0000 0001 2: 0000 0010 ... 255: 1111 1111 === Therefore if the number/value gets bigger than a byte for me it's just more natural to keep adding bits to the left of the sequence of bits (therefore big-endian style), for example: === 256: 1 0000 0000 257: 1 0000 0001 ... ===

ghusbands 5y ago
That amounts to the same question - the way we write binary numbers is the same way we write hexadecimal numbers, decimal numbers or numbers in any base; we start with the most significant. This makes the natural form for LTR languages big-endian. It has no bearing on the layout of bits in the RAM chips, caches, register files or data/address lines in a computer. Endianness pretty much only affects the operation of transferring values from/to memory.
- zepearl 5y ago
  Well, I can change the way I think/do stuff (I can write "1234" or "4321", no problem) but what I meant was basically "for me to make sense, byte-endianness should be aligned to bit-endianness"... . To me it would make sense to use little-endian if the same would be applied as well on the level of "bits" within a byte... . Using little-endian on a byte-level but big-endian on a bit-level (within a byte) is quite confusing for me. Just my subjective opinion.
yakubin 5y ago
> but in little-endian systems the order of the individual bits in a byte is still (kind of) big-endian, with the most meaningful bit on the left, right? Single bits are not addressable, so from the point of view of a programmer "order of bits" isn't well-defined. There isn't a way to distinguish endianness of bits for a programmer.