Quadibloc

2019-08-05 21:35:27 UTC

Generally speaking, the big-endian versus little-endian argument has been

interminable, and has generated more heat than light.

Historically, since computers were developed in the Western world, storage of

chracters in computer words was from "left" to "right", that is, from the most

significant part to the least significant part, basically without thought - it

was simply assumed to be the natural way to do it, as it corresponded to how

numbers and words were written by us on paper.

When advances in technology made it useful to build small-sized computers, with

a word length less than that of numbers it might be desired to calculate with on

those computers, some of those computers (one example is the Honeywell 316 and

related machines) would put the least significant part of a 32-bit number in the

first 16-bit word making it up.

This was done for the practical reason that adding two numbers together could

then proceed simply: go to the addresses where they're stored, get the least

significant parts first, add them, then use the carry from that for adding the

two most significant parts together.

The PDP-11 computer was a 16-bit computer made by Digital Equipment Corporation.

This company made aggressively priced minicomputers, but the PDP-11 was intended

to be more than just a run-of-the-mill minicomputer; instead of using an old-

fashioned ISA like that of DEC's own PDP-8 and PDP-4/7/9/15, or 16-bit machines

like the Honeywell 316 or the Hewlett-Packard 2115A, it was to be modern and

advanced, and in some ways similar to mainframes like the IBM System/360.

So, because it was to have a low price, it handled 32-bit numbers with their

least significant 16 bits first.

To make it less like an ordinary minicomputer, and more like a mainframe, the

byte ordering within a 32-bit integer was going to be consistent - like on the

System/360. It couldn't be ABCD, but instead of being CDAB, it could be DCBA.

Just put the first character in a 16-bit word in the least significant part, and

give that part the lower byte address!

This is how the idea of little-endian byte order was born.

The general belief today among computer scientists, it seems to me, is that the

industry should standardize on little-endian. Yes, big-endian seems more

familiar to people out of habit, but byte-order is just a convention.

Personally, I like big-endian myself. But I can see that it's an advantage that,

given that we address objects in memory by their lowest-addressed byte, the

place value for the first part is independent of length and thus always

constant.

But having the world of binary numbers used for arithmetic follow one rule, and

numbers as strings of ASCII characters that are read in and printed follow the

opposite rule... only works if those to worlds really are separate.

When the IBM System/360 came out, of course the PDP-11, which it partly helped

to inspire, didn't exist yet. So little-endian didn't exist as an alternative to

consider yet.

But despite that, if there had been a choice, big-endian would have been the

right choice for System/360.

The IBM System 360 mainframe, just like the microcomputer on your desktop,

handled character strings in its memory, even if they were in EBCDIC instead of

ASCII, and it also handled binary two's complement integers. (That was a bit of

a departure for IBM, as the 7090 used sign-magnitude.)

But it also had something else that Intel and AMD x86-architecture processors

only give very limited support to. Packed decimal numbers.

A packed decimal number is a way to represent numbers inside a computer as a

sequence of decimal digits, each one represented by four binary bits with the

binary-coded-decimal representation of that number.

The System/360 had pack and unpack instructions, to convert between numbers in

character string form and numbers in packed decimal form. Obviously, having both

kinds of numbers in the same order, with the first digit in the lowest address,

made those instructions easier to implement.

But the System/360 also *did arithmetic* with packed decimal quantities. And

they often used the same ALU, with a decimal adjust feature using nibble carries

turned on, to perform that arithmetic. So having the most significant part on

the same side of a number for binary numbers and packed decimal numbers made

_that_ easier.

Packed decimal numbers as an arithmetic data type, therefore, form a bridge

between numbers in character representation and numbers in binary

representation. As there are benefits from their byte ordering matching the byte

ordering of _both_ of those forms of numbers, their presence in a computer

architecture makes big-endian ordering advantageous for that architecture.

John Savard

interminable, and has generated more heat than light.

Historically, since computers were developed in the Western world, storage of

chracters in computer words was from "left" to "right", that is, from the most

significant part to the least significant part, basically without thought - it

was simply assumed to be the natural way to do it, as it corresponded to how

numbers and words were written by us on paper.

When advances in technology made it useful to build small-sized computers, with

a word length less than that of numbers it might be desired to calculate with on

those computers, some of those computers (one example is the Honeywell 316 and

related machines) would put the least significant part of a 32-bit number in the

first 16-bit word making it up.

This was done for the practical reason that adding two numbers together could

then proceed simply: go to the addresses where they're stored, get the least

significant parts first, add them, then use the carry from that for adding the

two most significant parts together.

The PDP-11 computer was a 16-bit computer made by Digital Equipment Corporation.

This company made aggressively priced minicomputers, but the PDP-11 was intended

to be more than just a run-of-the-mill minicomputer; instead of using an old-

fashioned ISA like that of DEC's own PDP-8 and PDP-4/7/9/15, or 16-bit machines

like the Honeywell 316 or the Hewlett-Packard 2115A, it was to be modern and

advanced, and in some ways similar to mainframes like the IBM System/360.

So, because it was to have a low price, it handled 32-bit numbers with their

least significant 16 bits first.

To make it less like an ordinary minicomputer, and more like a mainframe, the

byte ordering within a 32-bit integer was going to be consistent - like on the

System/360. It couldn't be ABCD, but instead of being CDAB, it could be DCBA.

Just put the first character in a 16-bit word in the least significant part, and

give that part the lower byte address!

This is how the idea of little-endian byte order was born.

The general belief today among computer scientists, it seems to me, is that the

industry should standardize on little-endian. Yes, big-endian seems more

familiar to people out of habit, but byte-order is just a convention.

Personally, I like big-endian myself. But I can see that it's an advantage that,

given that we address objects in memory by their lowest-addressed byte, the

place value for the first part is independent of length and thus always

constant.

But having the world of binary numbers used for arithmetic follow one rule, and

numbers as strings of ASCII characters that are read in and printed follow the

opposite rule... only works if those to worlds really are separate.

When the IBM System/360 came out, of course the PDP-11, which it partly helped

to inspire, didn't exist yet. So little-endian didn't exist as an alternative to

consider yet.

But despite that, if there had been a choice, big-endian would have been the

right choice for System/360.

The IBM System 360 mainframe, just like the microcomputer on your desktop,

handled character strings in its memory, even if they were in EBCDIC instead of

ASCII, and it also handled binary two's complement integers. (That was a bit of

a departure for IBM, as the 7090 used sign-magnitude.)

But it also had something else that Intel and AMD x86-architecture processors

only give very limited support to. Packed decimal numbers.

A packed decimal number is a way to represent numbers inside a computer as a

sequence of decimal digits, each one represented by four binary bits with the

binary-coded-decimal representation of that number.

The System/360 had pack and unpack instructions, to convert between numbers in

character string form and numbers in packed decimal form. Obviously, having both

kinds of numbers in the same order, with the first digit in the lowest address,

made those instructions easier to implement.

But the System/360 also *did arithmetic* with packed decimal quantities. And

they often used the same ALU, with a decimal adjust feature using nibble carries

turned on, to perform that arithmetic. So having the most significant part on

the same side of a number for binary numbers and packed decimal numbers made

_that_ easier.

Packed decimal numbers as an arithmetic data type, therefore, form a bridge

between numbers in character representation and numbers in binary

representation. As there are benefits from their byte ordering matching the byte

ordering of _both_ of those forms of numbers, their presence in a computer

architecture makes big-endian ordering advantageous for that architecture.

John Savard