4 ms·

LE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.

by nicce 2y ago

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.

LE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.

by 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.