linux-mips-fnet
[Top] [All Lists]

Re: m700-10 success

To: linux-mips@fnet.fr
Subject: Re: m700-10 success
From: Dom Sweetman <dom@algor.co.uk>
Date: Thu, 9 May 1996 21:33:17 +0100
In-reply-to: <199605091112.NAA30905@pallas.spacetec.no>
References: <dom@algor.co.uk> <199605091112.NAA30905@pallas.spacetec.no>
Reply-to: dom@algor.co.uk

> >PS: the "change endianness in user mode" feature was a late addition
> >    to the R3000 chip, by disgruntled MIPS engineers who wanted to be
> >    able to run DECstation binaries on MIPS Unix boxes.  The system
> >    software to make the hardware feature usable was never included in
> >    any MIPS OS, and I think has never been used by anyone.

> Interesting! I didn't know it could be done in user mode for MIPS, I
> thought it had to be done no later than during boot (I seem to
> remember a pin on the chip for this?).  I know PPC can be switched
> at any time, one task can run BE and the other LE -- at the same
> time even.  At least that's what I've been told.

Perhaps it's worth explaining a bit more.

Pretty much all MIPS CPUs ever have been configurable at startup for
endianness, in some way or another.  Choose big or little.  

The only difference in the CPU's operation is what byte lanes get used
when you do partial word loads and stores.

But the system around the CPU is often designed for one endianness.
It's committed in the following ways:

1. The CPU bus interface logic has to be able to figure out what byte
   lanes are active during partial-word transfers.  MIPS CPUs don't
   have straightforward per-byte "enable" signals (like x86's do); they
   give you a width code and a byte address.  So to work out where the
   data is, you need to know whether the CPU is being big or little.

2. The CPU's endianness imposes an implicit byte order on the bytes
   travelling along the different byte-lanes of the CPU bus; for BE
   CPUs the low-addressed-byte is the one on D24-31, while for LE CPUs
   the low-addressed byte is on D0-7.  So the hardware had better fit
   in, or anything outside the CPU which has a byte order (a diskette
   drive or network interface which does DMA, for instance) had better
   fit in.

To be able to work either way around the system *must* attend to (1);
(2), if wrong, can be painfully fixed around in software.

There are three groups of MIPS machines you're likely to meet up with:

o Workstations/computers from SGI and their "friends" Pyramid and
  Siemens-Nixdorf.  All big-endian, probably not adaptable.  SGI's
  success means that this is much the largest group of machines.

o DECstations and Sony workstations.  All little-endian, probably not
  adaptable. 

o PC's built during the great Windows/NT-on-MIPS scam.  All
  little-endian, usually not adaptable.  But very, very cheap.

[Advertisement mode on: I've never met a MIPS board which can work
 either way around, except the ones Algorithmics make.]

It used to be true that most 'embedded' MIPS applications seemed to
use the chip BE.  There's still a large majority of applications that
way, but recently a number of really big-volume applications have been
using little-endian.

Where should Linux be?  LE is more like a x86, so will cause less
porting trouble.  BE is more like SGI, but if you're planning on
running SGI binaries there's an awful lot of work to do - starting
with Unix SVR4-style shared libraries and running up through the SGI
3D graphics system.  If you're not planning to run SGI binaries, who
cares?

Doing only LE would rule out an SGI port; doing only BE means those of
you with Pica's and Deskstation PCs will need to throw them away.
Better stick with both.

So now, back to the 'reverse endianness in user mode' bit.  This got
added to the status register (MIPS for the CPU control register) just
in time to appear on the R3000 CPU.  What it does is make a BE CPU act
LE when it's in user mode (and vice versa); and was intended to be
implemented on a per-process basis in Unix, to allow a BE operating
system (ie MIPS Unix System V) to run LE binaries (ie DECstation
Ultrix binaries).

This shouldn't work (because partial-word transfers in this mode will
confuse the bus interface logic); but it's OK because user programs
usually only read/write cacheable locations, so only transfer data in
whole-word or bigger units.

The software results are pretty nasty, because the BE view of LE data
is consistent only for aligned objects of CPU-bus-width size -
doublewords on R4x00, words on R3000.  *Everything* which passes
between kernel and application needs to be swapped byte-within-[word
or doubleword] (to restore consistent byte addressing) and then
swapped again in a data dependent way (to resolve the difference
between LE and BE ideas of shorts, integers, floats).  As someone
said, the fact that Linux is living on a crummy architecture (x86)
where the kernel can't read from user-space pointers may help localise
the problem.

In practice, the software job of emulating enough of the Ultrix system
call interface over SystemV was too big for MIPS - the idea was a
symptom of the megalomania which ultimately led the company to the
edge of bankruptcy (and into SGI's, fortunately friendly, arms).

As for emulating Ultrix over Linux, or MIPS/ABI over Linux... sounds
pretty yukky to me.  But with lots of effort it might let you build LE
and BE Linux kernels, but run the same binaries on both.  Any heroes
out there?

-- 
Regards,

Dominic Sweetman                phone: +44 171 700 3301
Algorithmics Ltd                home:  +44 171 226 0032
3 Drayton Park                  fax:   +44 171 700 3400
London N5 1NU                   email: dom@algor.co.uk
ENGLAND.                        www:   http://www.algor.co.uk
                                ftp:   ftp.algor.co.uk

<Prev in Thread] Current Thread [Next in Thread>