7 ms·

I wonder whether that's due to any technical merit of little endianness or just because of x86's dominance in the desktop/workstation world?

by plq 6y ago

moonchild 6y ago
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.
jzwinck 6y ago
Little endian has one nice feature for network communication: integer fields can be expanded or shrunk without changing code of the peer so long as the actual numbers don't overflow. Most mainstream protocols don't really take advantage of this because it is error prone, but it is used sometimes.
- kaszanka 6y ago
  I don't understand, wouldn't all of the fields after the expanded/shrunk one become misaligned?
  - jzwinck 6y ago
    It only works if you have some way to know where the next field or message starts. Sometimes you do, sometimes you don't.
gsnedders 6y ago
A lot of it is simply the prevalence of little-endian systems, initially with x86, but now with the vast majority of other systems too; code is developed on the developer's system, and works there. As big-endian systems have become increasingly rare, an ever larger amount of code has stopped working (or never worked) on big-endian systems, thus it's become harder and harder to ship big-endian systems. If you want desktop-class applications, they've typically either been little-endian only, or have been little-endian only since Apple migrated to Intel. We've seen POWER largely migrate to little-endian, as IBM was struggling with sales due to the difficulty in porting software to it, partly due to the endianness difference. (Note that POWER and PowerPC were technically always bi-endian architectures, but the majority of historic hardware had its endianness set by the motherboard in use, and almost everything shipped with big-endian. Systems running Windows NT on PowerPC were some of the very few that ran in little-endian mode.) We've also seen a similar shift in embedded hardware; bi-endian architectures like ARM and MIPS are now more commonly used in little-endian mode, despite historically being used in big-endian mode.

I wonder whether that's due to any technical merit of little endianness or just because of x86's dominance in the desktop/workstation world?

by plq 6y ago

I wonder whether that's due to any technical merit of little endianness or just because of x86's dominance in the desktop/workstation world?

moonchild 6y ago

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.

jzwinck 6y ago

Little endian has one nice feature for network communication: integer fields can be expanded or shrunk without changing code of the peer so long as the actual numbers don't overflow. Most mainstream protocols don't really take advantage of this because it is error prone, but it is used sometimes.

kaszanka 6y ago
I don't understand, wouldn't all of the fields after the expanded/shrunk one become misaligned?
- jzwinck 6y ago
  It only works if you have some way to know where the next field or message starts. Sometimes you do, sometimes you don't.

gsnedders 6y ago

A lot of it is simply the prevalence of little-endian systems, initially with x86, but now with the vast majority of other systems too; code is developed on the developer's system, and works there. As big-endian systems have become increasingly rare, an ever larger amount of code has stopped working (or never worked) on big-endian systems, thus it's become harder and harder to ship big-endian systems. If you want desktop-class applications, they've typically either been little-endian only, or have been little-endian only since Apple migrated to Intel. We've seen POWER largely migrate to little-endian, as IBM was struggling with sales due to the difficulty in porting software to it, partly due to the endianness difference. (Note that POWER and PowerPC were technically always bi-endian architectures, but the majority of historic hardware had its endianness set by the motherboard in use, and almost everything shipped with big-endian. Systems running Windows NT on PowerPC were some of the very few that ran in little-endian mode.) We've also seen a similar shift in embedded hardware; bi-endian architectures like ARM and MIPS are now more commonly used in little-endian mode, despite historically being used in big-endian mode.