What about some examples to make things clear?
500 decimal is 0x1f4 in hex (256 + 15 * 16 + 4)
in a big endian halfword (2 bytes), this looks like 01 F4
big endian fullword (4 bytes): 00 00 01 F4
when processed by a 32 bit machine (for example IBM mainframe),
both representations (2 bytes and 4 bytes) will be processed in a 32 bit
register,
that is, the value will be expanded to
00 00 01 F4
More interesting with negative values: -500 = FE 0C (2 Bytes) = FF FF FE
0C (4 Bytes)
The 2 Bytes value is expanded to 4 Bytes by propagating the leftmost bit
(which is 1
on negative values) to the left.
Now little endian (the PC representation):
the Intel CPUs have 16 bit registers and today even 32 bit registers
(AFAIK).
Binary values in registers are represented exactly the same, but in the
main storage
(and on files etc.), binary data is stored in reverse order (bites
swapped).
For example:
500 binary stored in 2 bytes looks like F4 01
500 binary stored in 4 bytes looks like F4 01 00 00
When loaded in a CPU register, the first byte (with the lowest address)
goes into the "right" position of the register (the least significant 8
bits)
and so on ...
Same goes for negative values, of course:
- 500 in 2 bytes = 0C FE
- 500 in 4 bytes = 0C FE FF FF
My explanation for these differences goes like this:
big endian solutions are natural for machines which provide a "word"
access to the
storage and which have (for example) 32 bit CPU registers from the
start. BTW,
we had a 48 bit machine in Germany; the 48 bit word could be accessed
alternatively
as two 24 bit halfwords; of course, both number representations were big
endian, too.
little endian solutions are inspired by computers which originally had 8
bit word size,
which is true for the PDPs (AFAIK) and for the 8080 and Z80s, which were
the anchestors
of the PC hardware (8086). Because of their restricted instruction set
and register size,
there was no other solution than to process longer numbers byte by byte,
and in that
case it is better if the least significant bytes are stored first in
storage. This was never
changed, although later more powerful processors were available.
BTW: when I was studying computer science in the late 1970s, we had to
write a program
for an 8080 processor, assemble it manually and then enter it into the
storage
of some sort of test platform via switches. But nobody told us before
about this
endianness topic. We had no idea of this, because we only knew big
endian machines
before. We only got some information about the instruction set, some
information
about how to handle the test platform and the problem which we had to
solve -
and 2 or 3 hours time to do it. Only 15 minutes before the exercise
started,
someone told us that all numbers have to be stored in the "opposite"
order :-(
all our preparation had to be reworked in a hurry ... that was no fun,
but in
the end we succeeded :-)
Kind regards
Bernd
Am 17.06.2017 um 01:29 schrieb David W Noon:
On Fri, 16 Jun 2017 17:56:42 -0500, Paul Gilmartin
([email protected]) wrote about "Re: RFE?
xlc compile option for C integers to be "Intel compat" or Little-Endian"
(in <[email protected]>):
On Fri, 16 Jun 2017 22:56:18 +0100, David W Noon wrote:
[snip]
The endianness is determined by where the MSB and LSB are stored. On IBM
machines the MSB is in the left-most byte of the register and the LSB in
the right-most byte. That is big-endian.
Ascribing indices to the bit positions in either order makes no
difference. It is the order of *storage* that determines endianness.
??? We're talking about *registers* here. See your first paragraph I quoted.
What do you mean by "the order of *storage*" of bits in a register
other than how one ascribes indices? If I rotate my laptop 180° on
my desk, have I swapped the left end and the right end?
The bytes are ordered, otherwise shift instructions would produce rather
random results. The bits are ordered within bytes; that ordering remains
fixed (i.e. bits are never reversed when loading/storing), even during
shift instructions as bits are shifted in and out.
You can see the byte ordering when coding an ICM or STCM instruction.
These instructions have a bit mask to select affected bytes and the
bytes are ordered in the same order as the bit mask -- and it is big-endian.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
