Re: [OT] The Ramifications of Little-Endian Packed Decimal

From: John Mashey (old_systems_guy_at_yahoo.com)
Date: 02/29/04 

Date: 28 Feb 2004 18:27:40 -0800

Andrew Reilly <andrew@gurney.reilly.home> wrote in message news:<pan.2003.08.20.23.49.20.467962@gurney.reilly.home>...
> On Wed, 20 Aug 2003 13:51:18 +0000, jsavard wrote:
> > So, after I considered this - after seeing the cataclysmic results of
> > changing the bit while executing code whose interpretation is affected by
> > it, on a system that implements endianness-change by means of bit munging
> > - I realized there was _another_ alternative.
> >
> > Define endianness in the *segment registers*, so that you can change the
> > data segment from big-endian to little-endian while leaving the code
> > segment alone!
>
> Sorry for butting in late into this thread, but could you please give a
> quick summary for why this capability would be at all useful? Can't
> imagine it, myself.

HISTORY: WHERE DID DUAL-BYTE ORDER IN MICROS COME FROM?
1) I think MIPS R2000 was the first microprocessor to do this;
in any case, the relevant patent is US 4,959,779:
Weber, Hansen, Riordan, Przbylski, "Dual byte order computer
architecture
a functional unit for handling data sets with different byte orders",
filed 1988, granted 1990.

2) The R2000 was originally Big-Endian-only (BE), but in early Summer
of 1985
we added the original byte-order bit, settable only at RESET time.
(I.e., given that MIPS was formed in late 1984, most of the deisgn was
settled
by 2Q85, this was a very late addition to the design.)

3) It was originally BE because the target markets were:
  a) UNIX workstation/server, dominated at the time by Motorola 68XXX;
     also, IBM mainframes were BE.
  b) High-end embedded, likewise 68XXX, and generally many embedded
customers
     were "don't care very much".

  It was not particularly expected that dedicated-LE companies (like
DEC)
  would be customers.

WHY BE/LE?
4) We were talking to Daisy, who basically said that for them to even
  consider using MIPS, it simply had to support LE.
  a) Somebody (I think Tom Riordan) observed that since we already had
  8/16/32-bit load-stores [i.e., lots of byte rerragement wires in the
  load/store path], we could add LE support with minimal die space and
  no cycle time penalties.
  b) Our compiler technology was already pretty clean with regard to
byte
  order, and we were using tools like Earl Killian's MOXIE, which
  took a linked MIPS binary and converted to VAX code for testing.
  So software was not viewed as a barrier.
  c) So we decided to put it in for Daisy, and possible other future
  customers who might demand LE. Daisy didn't turn out to be a
customer.
  All of the early MIPS customes used BE.
  d) Byte-order-on-reset-only was viewed as plenty adequate for the
time,
  as none of us knew anybody who wanted to mix them dynamically.

5) Of course, in 1988, there was DEC. Although some people wanted to
  use BE MIPS to keep the MIPS-based workstations "fenced off" from
VAXen,
  the ability to run LE removed an objection [all DEC systems were
LE.]
  Note: without DEC as a customer, it is unlikely that MIPS would have
  gotten the semiconductor partners that it did, and the 1989 IPO
might not
  have happened.

6) Later, in the R4000 (1991), we added a "Reverse Endian" bit to the
  Status Register, which could be set before kernel->user switch,
  to allow opposite-byte-order processes to be run. This was done
  with thoughts like:
  a) Maybe DEC Ultrix binaries could be run on RISCos.
  b) And later, maybe Windows NT-MIPS binaries could be run on RIScos,
IRIX...
  
  And there were experiments that actually worked, but never shipped.

7) During the early 1990s, when Windows NT was really getting going,
  Microsoft was very clear: there would NEVER be an NT port to a BE
CPU.
  I believe that this may have induced others to add LE compatibility
  to BE CPUs, "just in case."

OPINION OF DUAL BYTE ORDER
1) In general, the feature is primarily worthwhile only for market
extension with customers who are 100% committed to one byte order or
the other.
The feature was certainly worthwhile for MIPS, as it enabled a crucial
(and not originally expected) design win at DEC.

2) It is a modest hassle for software to have to deal with this, and I
can't think offhand of any vendor who ever used MIPS both ways in a
product line.

3) As far as I can tell, the use of per-process by-order selection,
despite existing since 1991, has not been particularly useful.
However, it's not very expensive to support the simpler flavors of
this,
so it's not particularly harmful, and for a chip vendor, can
occasionally
be useful in market extension.

4) If I were designing a CPU, I'd NEVER spend a lot of effort trying
to
optimize this feature, or make it cooler or better... without some
compelling new evidence that it would matter to somebody specific.