5 ms·

Little endian is better. Most arithmetic needs to start with the less significant bits, so it's better to have them be accessible first. (E.G. most bignum rep

Little endian is better. Most arithmetic needs to start with the less significant bits, so it's better to have them be accessible first. (E.G. most bignum representations also use little-endian, even though they don't have to.) Little endian also allows you to truncate integers more easily.

codesnik 6y ago
but it's really weird to look on those in hexdump
- Artlav 6y ago
  And that's another reason - gone are the days when code was written in machine language by people looking at bytes, and with it gone the only reason to keep these bytes in human-readable form. It's the same kind of thing as computers and calculators switching from decimal hardware to binary hardware 100 years ago.
  - twic 6y ago
    People still routinely look at data in hexdumps, and little-endian is still as irritating as it ever was.
  - DerekL 6y ago
    > It's the same kind of thing as computers and calculators switching from decimal hardware to binary hardware 100 years ago. Not quite. ENIAC, for example, did calculations in decimal, and it was finished in 1945. There may be more recent examples. If you include binary-coded decimal, that still includes machines made in 1970 or later, like the IBM 1401. https://en.wikipedia.org/wiki/IBM_1401 https://en.wikipedia.org/wiki/IBM_1401 https://news.ycombinator.com/item?id=25523904 https://news.ycombinator.com/item?id=25523904
viraptor 6y ago
Does it actually matter these days? Registers can be wired in any way physically, so there's no "first byte" on that level. It would only matter if there was an instruction pipeline optimising an 8bit bus reading the long value into ALU input and ALU doing the operation... which as far as I understand modern design doesn't actually happen.
- adrian_b 6y ago
  The parent meant that it matters for multi-word numbers, where the endianness becomes visible. In the days of 8-bit microprocessors, the endianness became visible in software from 16-bit numbers up. Now it might be visible only for numbers above 64-bit on many CPUs, but there is always a number size above which you must take endianness into account, even for the simplest operations, like comparing and adding. In theory, you could choose the layout of a large number to have mixed endianness, e.g. to have a large number as a little-endian sequence of 64-bit chunks, where the 64-bit chunks are big-endian, because the CPU used is BE. However that might make the algorithms even more complex than when you use a consistent endianness. The endianness of a CPU is not visible in software only when the addressing unit of the memory is the same as the data register size of the CPU. All modern CPUs have register sizes of either 32-bit or 64-bit, while the memory is addressed in bytes, so the endianness will continue to matter in the foreseeable future.
- moonchild 6y ago
  Registers don't have endianness. Memory does.
deleted 6y ago
[deleted]
twic 6y ago
> Most arithmetic needs to start with the less significant bits, so it's better to have them be accessible first. (E.G. most bignum representations also use little-endian, even though they don't have to.) Some operations start at the least significant end, some start at the most significant end, and it's equally easy to loop over the words in either direction, so i don't buy this. > Little endian also allows you to truncate integers more easily. What do you mean by truncate an integer? If you mean go from 32 bit to 16 bit, that's still trivial with big-endian, you just shift.
- moonchild 6y ago
  > If you mean go from 32 bit to 16 bit, that's still trivial with big-endian, you just shift. Surely you would agree that moves are easier than shifts? Moves can be handled by the renamer and be effectively free (even for memory operands, on CISC, with the advent of memory renamers; but this is even more important for RISC, where what would otherwise have been a load followed by a shift can just be a load), whereas shifts cannot and must take up some fraction of a cycle.
daneel_w 6y ago
It's a legacy from days of old when it made silicon design of the memory bus easier. Arm, for example, does not incur a performance hit when switching to big-endian.

codesnik 6y ago

but it's really weird to look on those in hexdump

Artlav 6y ago
And that's another reason - gone are the days when code was written in machine language by people looking at bytes, and with it gone the only reason to keep these bytes in human-readable form. It's the same kind of thing as computers and calculators switching from decimal hardware to binary hardware 100 years ago.
- twic 6y ago
  People still routinely look at data in hexdumps, and little-endian is still as irritating as it ever was.
- DerekL 6y ago
  > It's the same kind of thing as computers and calculators switching from decimal hardware to binary hardware 100 years ago. Not quite. ENIAC, for example, did calculations in decimal, and it was finished in 1945. There may be more recent examples. If you include binary-coded decimal, that still includes machines made in 1970 or later, like the IBM 1401. https://en.wikipedia.org/wiki/IBM_1401 https://en.wikipedia.org/wiki/IBM_1401 https://news.ycombinator.com/item?id=25523904 https://news.ycombinator.com/item?id=25523904

viraptor 6y ago

Does it actually matter these days? Registers can be wired in any way physically, so there's no "first byte" on that level. It would only matter if there was an instruction pipeline optimising an 8bit bus reading the long value into ALU input and ALU doing the operation... which as far as I understand modern design doesn't actually happen.

adrian_b 6y ago
The parent meant that it matters for multi-word numbers, where the endianness becomes visible. In the days of 8-bit microprocessors, the endianness became visible in software from 16-bit numbers up. Now it might be visible only for numbers above 64-bit on many CPUs, but there is always a number size above which you must take endianness into account, even for the simplest operations, like comparing and adding. In theory, you could choose the layout of a large number to have mixed endianness, e.g. to have a large number as a little-endian sequence of 64-bit chunks, where the 64-bit chunks are big-endian, because the CPU used is BE. However that might make the algorithms even more complex than when you use a consistent endianness. The endianness of a CPU is not visible in software only when the addressing unit of the memory is the same as the data register size of the CPU. All modern CPUs have register sizes of either 32-bit or 64-bit, while the memory is addressed in bytes, so the endianness will continue to matter in the foreseeable future.
moonchild 6y ago
Registers don't have endianness. Memory does.

deleted 6y ago

[deleted]

twic 6y ago

> Most arithmetic needs to start with the less significant bits, so it's better to have them be accessible first. (E.G. most bignum representations also use little-endian, even though they don't have to.) Some operations start at the least significant end, some start at the most significant end, and it's equally easy to loop over the words in either direction, so i don't buy this. > Little endian also allows you to truncate integers more easily. What do you mean by truncate an integer? If you mean go from 32 bit to 16 bit, that's still trivial with big-endian, you just shift.

moonchild 6y ago
> If you mean go from 32 bit to 16 bit, that's still trivial with big-endian, you just shift. Surely you would agree that moves are easier than shifts? Moves can be handled by the renamer and be effectively free (even for memory operands, on CISC, with the advent of memory renamers; but this is even more important for RISC, where what would otherwise have been a load followed by a shift can just be a load), whereas shifts cannot and must take up some fraction of a cycle.

daneel_w 6y ago

It's a legacy from days of old when it made silicon design of the memory bus easier. Arm, for example, does not incur a performance hit when switching to big-endian.