55 ms·

Well, the bits jump around.. bytes are ordered, but the bits aren't, with LE (between bytes) so there's always room for a never-ending discussion about what's b

by Tor3 2y ago

Well, the bits jump around.. bytes are ordered, but the bits aren't, with LE (between bytes) so there's always room for a never-ending discussion about what's best ("Are you a bit person? Or a byte person? Then your preferences may differ"). The best argument for LE would be that a processor like e.g. the 6502 could start processing the least significant byte while fetching the most significant byte, and that on a VAX you could pass a 4-byte integer to a Fortran function expecting a 2-byte integer and it would actually work (as long as the value was > 65536). That was actually done a lot back in the day.. and created problems when recompiling the Fortran code for a BE architecture.

deleted 2y ago
[deleted]
akira2501 2y ago
LE is easier to handle, BE is easier to read.
- nicce 2y ago
  LE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.
  - bregma 2y ago
    At the circuit level (where the performance is determined) it doesn't matter if your half-adder combines its left and right inputs or its right and left inputs. So no, there is no difference in efficiency or performance when it comes to endianness. The only time it would make a difference is if your memory bus width is less than your wordsize and you lack any kind of caching.
  - foldr 2y ago
    I wonder if you're thinking of the efficiency penalty for dealing with big-endian values on a little-endian architecture. As the sister comment says, there's nothing inherently more efficient about either byte order when it comes to the processor performing arithmetic operations in on values in its native byte order.
  - p_l 2y ago
    Unless you have a bit-serial machine (close to extinct), LE vs BE matters not for ALU so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic)
    - Tor3 2y ago
      .. or a 6502 microprocessor doing 16-bit arithmetic with an 8-bit ALU. The 6502 was designed by a team who used to work with the big endian 6800, and chose little endian for their 6502 for a slight performance improvement.
      - p_l 2y ago
        That falls into my second case of using smaller ALU in two steps :)
    - magicalhippo 2y ago
      > so long as you don't have to run the computation through multiple rounds To be fair, this is not exactly uncommon for many workloads, even on todays 64bit machines.
    - danbruc 2y ago
      [...] so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic) That does not sound right, your byte ordering should not affect the ALU, it will always perform the same operations. If you are doing a multi-word add, you have to add from least significant to most significant word because of the carry. And the ALU has no idea what you are adding, whether the numbers are independent or part of a multi-word integer. At best I could imagine that there might be some impact when fetching operands as in big-endian you have to fetch from decreasing addresses which might be less efficient then fetching from increasing addresses.
Tor3 2y ago
I had another look at the actual article/RFC: This is more than just the little endian/big endian byte order, it's about the bit order of serial messages, where, unlike bytes, the bit order could actually be different (for bytes stored in memory the bits of each individual byte in modern / semi-modern computers are always stored in the same order whether it's a LE or a BE memory architecture). In a serial protocol you could send the most significant bit of the stream first, or the least significant bit first, and that's what's at first discussed in that RFC.
- kstenerud 2y ago
  Yes, that's right. Since CPUs abstract away the bit ordering, it only starts to matter when dealing with bit-oriented communications. And since it is abstracted away, there's no real benefit to be gained by BE or LE at the bit-level.

by Tor3 2y ago

deleted 2y ago

[deleted]

akira2501 2y ago

LE is easier to handle, BE is easier to read.

nicce 2y ago
LE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.
- bregma 2y ago
  At the circuit level (where the performance is determined) it doesn't matter if your half-adder combines its left and right inputs or its right and left inputs. So no, there is no difference in efficiency or performance when it comes to endianness. The only time it would make a difference is if your memory bus width is less than your wordsize and you lack any kind of caching.
- foldr 2y ago
  I wonder if you're thinking of the efficiency penalty for dealing with big-endian values on a little-endian architecture. As the sister comment says, there's nothing inherently more efficient about either byte order when it comes to the processor performing arithmetic operations in on values in its native byte order.
- p_l 2y ago
  Unless you have a bit-serial machine (close to extinct), LE vs BE matters not for ALU so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic)
  - Tor3 2y ago
    .. or a 6502 microprocessor doing 16-bit arithmetic with an 8-bit ALU. The 6502 was designed by a team who used to work with the big endian 6800, and chose little endian for their 6502 for a slight performance improvement.
    - p_l 2y ago
      That falls into my second case of using smaller ALU in two steps :)
  - magicalhippo 2y ago
    > so long as you don't have to run the computation through multiple rounds To be fair, this is not exactly uncommon for many workloads, even on todays 64bit machines.
  - danbruc 2y ago
    [...] so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic) That does not sound right, your byte ordering should not affect the ALU, it will always perform the same operations. If you are doing a multi-word add, you have to add from least significant to most significant word because of the carry. And the ALU has no idea what you are adding, whether the numbers are independent or part of a multi-word integer. At best I could imagine that there might be some impact when fetching operands as in big-endian you have to fetch from decreasing addresses which might be less efficient then fetching from increasing addresses.

Tor3 2y ago

I had another look at the actual article/RFC: This is more than just the little endian/big endian byte order, it's about the bit order of serial messages, where, unlike bytes, the bit order could actually be different (for bytes stored in memory the bits of each individual byte in modern / semi-modern computers are always stored in the same order whether it's a LE or a BE memory architecture). In a serial protocol you could send the most significant bit of the stream first, or the least significant bit first, and that's what's at first discussed in that RFC.

kstenerud 2y ago
Yes, that's right. Since CPUs abstract away the bit ordering, it only starts to matter when dealing with bit-oriented communications. And since it is abstracted away, there's no real benefit to be gained by BE or LE at the bit-level.