[OT] The Ramifications of Little-Endian Packed Decimal

jsavard_at_ecn.ab.ca
Date: 08/10/03 

Date: Sun, 10 Aug 2003 14:17:42 GMT

This is posted to sci.crypt, as well as comp.arch, because it wasn't long
ago that we had a discussion there about the difference between big-endian
and little-endian computers.

On my web page, at

http://home.ecn.ab.ca/~jsavard/other/arc02.htm

you will see a big highlighted box in the description of packed decimal
instructions for a hypothetical computer architecture I have been
describing.

Some computers store binary data with the most significant portion first,
and some do so with the least significant portion first. The latter has
some arguments for it in efficiency of arithmetic; the former allows
magnitude comparisons to be more consistent, and is more easily understood
by people whose cultural background includes using Hindu-Arabic numerals
in conjunction with a left-to-right direction of writing.

Well, after adding multiple floating-point formats to the architecture, I
decided that if I was going to set up for compatibility with other
machines, I had better also allow little-endian operation, however much I
preferred big-endian operation (most significant part first, in the lower
address).

However, I was also supporting packed decimal data, like the System/360.

At first, I thought I could just make packed decimal big endian regardless
of whether binary data was little endian. This would make it consistent
with the character data into which ease of conversion was the entire
raison d'etre of packed decimal.

But I realized that if I was going to use the impolitely-named "bit
munging" as an implementation technique for little-endian operation, I
would then be forced at least to load packed decimal quantities into the
ALU serially by byte.

So I couldn't do that! So instead, I had to store them in little-endian
fashion... and address them by their byte at the highest address, unlike
all other data values, when in little-endian mode.

However, that would be perverse if the users of the computer were speakers
of Arabic or Hebrew, where the order of characters in numeric strings
relative to text is reversed, and in which little-endian operation makes
sense. Thus, I had to add a *second* bit to the program status word, to
describe the endianness of character, as opposed to computational, numeric
values.

This illustration of just how complicated endianness is (and a warning on
my main page,

http://home.ecn.ab.ca/~jsavard/other/arcint.htm

hinting at what happens when you don't have separate code and data
segments, and you turn on bit munging for all addresses, _including those
generated from the program counter contents_, in the middle of execution)
may possibly be of some relevance to the ongoing debate on this topic.

John Savard

Relevant Pages

  • Re: "Hell of a Fix," Matthew Hughes
    ... Once computers uniformly *natively* had octets on each end of the ... so the network protocols commonly were big-endian; ... n An unsigned short in "network" order. ... v An unsigned short in "VAX" (little-endian) order. ...
    (rec.arts.sf.written)
  • Re: little endian or big endian ???
    ... little-endian or big-endian. ... "It is important to remember that when it comes to law, computers ... Only people can be given permission." ...
    (comp.lang.c)
  • Re: I think the standard will be on my side (BOZ)
    ... (snip, I wrote) ... That should be endian independent. ... not only is the bit address (POS) ... (in increasing order according to little-endian convention). ...
    (comp.lang.fortran)
  • Re: I think the standard will be on my side (BOZ)
    ... So the use of BOZ consants is not the ... That should be endian independent. ... The bit model numbers bits from the right - that's little-endian. ... The standard is consistently little-endian, ...
    (comp.lang.fortran)
  • Re: About little big endian in C
    ... I supposed that, techincally, the answer is incomplete at best. ... systems, is "endianness" even relevent?) ... then I guess it is little-endian and big-endian at the same time, ...
    (comp.lang.c)
Quantcast