3 ms·
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 (
by 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 agoThat 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.