5 ms·
> correspond to a binary format in accordance with the C ABI on your particular system. We're so deep in this hole that people are fixing this on a CPU with si
by gopalv 7mo ago
> correspond to a binary format in accordance with the C ABI on your particular system.
We're so deep in this hole that people are fixing this on a CPU with silicon.
The Graviton team made a little-endian version of ARM just to allow lazy code like this to migrate away from Intel chips without having to rewrite struct unpacking (& also IBM with the ppc64le).
Early in my career, I spent a lot of my time reading Java bytecode into little endian to match all the bytecode interpreter enums I had & completely hating how 0xCAFEBABE would literally say BE BA FE CA (jokingly referred as "be bull shit") in a (gdb) x views.
- wahern 7mo agoGCC supports specifying endianness of structs and unions: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Common-Type-Attributes.html#index-scalar_005fstorage_005forder-type-attribute https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Common-Type-At... I'm not sure how useful it is, though it was only added 10 years ago with GCC 6.1 (recent'ish in the world of arcane features like this, and only just about now something you could reasonably rely upon existing in all enterprise environments), so it seems some people thought it would still be useful.
- torginus 7mo agoI thought all iterations of ARM are little endian, even going back as far to ARM7. same as x86? The only big-endian popular arch in recent memory is PPC
- masklinn 7mo agoAFAIK ARM is generally bi-endian, though systems using BE (whether BE32 or BE8) are few and far between.
- kevin_thibedeau 7mo agoIt started as LE and added bi-endian with v3.
- zombot 7mo agoFuck, the stupidity of humans really is infinite.
- api 7mo agoARM is usually bi-endian, and almost always run in little endian mode. All Apple ARM is LE. Not sure about Android but I’d guess it’s the same. I don’t think I’ve ever seen BE ARM in the wild. Big endian is as far as I know extinct for larger mainstream CPUs. Power still exists but is on life support. MIPS and Sparc are dead. M68k is dead. X86 has always been LE. RISC-V is LE. It’s not an arbitrary choice. Little endian is superior because you can cast between integer types without pointer arithmetic and because manually implemented math ops are faster on account of being linear in memory. It’s counter intuitive but everything is faster and simpler. Network data and most serialization formats are big endian by convention, a legacy from the early net growing on chips like Sparc and M68k. If it were redone now everything would be LE everywhere.
- amluto 7mo ago> Little endian is superior because you can cast between integer types without pointer arithmetic I’ve heard this one several times and it never really made sense. Is the argument that y you can do: short s; long *p = (long*)&s; Or vice versa and it kind of works under some circumstances?
- elehack 7mo agoYes. In little-endian, the difference between short and long at a specific address is how many bytes you read from that address. In big-endian, to cast a long to a short, you have to jump forward 6 bytes to get to the 2 least-significant bytes.
- lxgr 7mo agoWow, I've been living life assuming that little endian was just the VHS of byte orders with no redeeming qualities whatsoever until today. This actually makes sense, thank you!
- hyc_symas 7mo agoNetwork data and most serialization formats are big endian because it's easiest to shift bits in and out of a shift register onto a serial comm channel in that order. If you used little endian, the shifter on output would have to operate in reverse direction relative to the shifter on input, which just causes stupid inconsistency headaches.
- yjftsjthsd-h 7mo ago> The Graviton team made a little-endian version of ARM just to allow lazy code like this to migrate away from Intel chips without having to rewrite struct unpacking No? Most ARM is little endian.
- direwolf20 7mo agoARM has always been little-endian. Some were configurable endian. And it's not a hole. We're not about to spend 100 cycles parsing a decimal string that could have been a little-endian binary number, just because you feel a dependency on a certain endianness is architecturally impure. Know what else is architecturally impure? Making binary machines handle decimal.
- ozgrakkurt 7mo agoI would question why is it big endian in the first place. Little endian is obviously more popular, why use big endian at all?