Big endian vs little endian

Big endian vs little endian

I think it important to remember that when the IBM System/360 was announced on 01 APR 1964 as an all around scientific -and- commercial data processing device (yes, "data processing"; "information technology" had net even been coined, then) that the primary purpose for even commercial processing was for numerical processing! Text processing was just something else it did, some times with a move command, but usually with a sub-routine which utilized specialized text processing instructions. Also, while its native mode was Enhanced Binary Coded Decimal for Interchange Code -- EBCDIC -- all instructions had an ASCII-bit for switching to ASCII interpretation. ASCII was new at the time. From 1964 until today I have never heard of anyone actually using the ASCII-bit. EBDCIC was an extension/enhancement to the code structure which had been used in IBM's previous mainframes -- both commercial and scientific oriented number processors.

System/360 operated with 32-bit and 64-bit instructions. And, yes, some few instructions worked on only 16-bit or 8-bit at a time. A decimal number, e.g 750124, was converted, by the hardware into a series of hexadeciminal units. Hexadecimal had the advantage that the hex-bits laid out the same way, left-to-right, in HEX, BCD, EBCDIC, the way they were written on a bank check (for instance) and the same way they would have been punched into an IBM-card.

Inside the CPU a single instruction could fetch a customer's entire record. A second instruction could load the customer's account balance into a register of choice. The third instruction could subtract the customer's bank check payment from that resister, after which a fourth instruction stored the resulting new balance back into the customer's record. Finally a fifth instruction would write the updated record back onto a designated storage device. There was no bit manipulation. Just Bif!, Bam! And that was all using assembler language instructions!

Such was the power of a "big iron" instruction set with big-endian data representation. Multiple, i.e. sixteen, 32-bit registers cost big time and instruction set execution which could process such registers (or pairs of such registers for 64-bit operations) in one cycle was expensive.

The Intel 4000-series (4004, etc.) and 8000-series (8008, 8080, etc.) understandably took a different approach. IBM's main customers were primarily insurance companies which were drowning in a sea of paper record processing and desperately needed to automate or die. (Word was than many sent clerks to IBM programming school; those which passed still had jobs.)

Years later, Intel's 4000/8000 customers were, originally, vending machine manufactures who wanted to escape the break-down prone mechanical change-making processors which were then being used in machines which sold more than one-type, one-price product. Little-endian programming seemed appropriate for such (no insult intended) nickel-and-dime processing using a minimal instruction set. {Intel counted adding to A-reg and adding to B-reg as two different instructions; IBM counted a instruction which could add to any register, 0 through 15, as one instruction.]

IMHO, I prefer big-iron type powerful instruction sets which operate in one fell swoop on entire chunks of data using open-source code and open-format data representation. It takes billions of us to operate this planet and anyone who feels the need or urge ought to be able to have a fair go at it and, if successful leave behind a trail others can extend. {Well, that's my 64 bits worth! :) Thanks for reading if you stayed this far.}