Re:Byte Ordering: On Holy Wars and a Plea for Peace (1980)
by p_l on Monday September 16, 2024 @07:29AM
(#41554962)
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)
[ Parent
| on HN ]
Re:Byte Ordering: On Holy Wars and a Plea for Peace (1980)
by Tor3 on Monday September 16, 2024 @08:24AM
(#41555344)
.. 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.
Re:Byte Ordering: On Holy Wars and a Plea for Peace (1980)
by p_l on Monday September 16, 2024 @10:09AM
(#41556239)
That falls into my second case of using smaller ALU in two steps :)
Re:Byte Ordering: On Holy Wars and a Plea for Peace (1980)
by magicalhippo on Monday September 16, 2024 @11:36AM
(#41557137)
> 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.
Re:Byte Ordering: On Holy Wars and a Plea for Peace (1980)
by danbruc on Monday September 16, 2024 @11:47AM
(#41557277)
[...] 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.