Re: Questions?

[Dominic Sweetman <dom@algor.co.uk>]

Ralf Baechle (ralf@oss.sgi.com) writes:

> The MIPS ABI only covers big endian systems - every "real" MIPS UNIX
> system is big endian.

Except Decstations.  And Sony NeWS (remember that one).  And anything
running on those NEC Vr41xx systems which were designed for WinCE and
don't run big-endian at all.  There never was a consensus...

Mapping the MIPS ABI to little-endian presents no problems, as far as
I know: obviously since it's a binary compatibility standard it has to
make a choice...

> There is hardly any reason to choose a particular byteorder as
> usually endianess swapping takes so little CPU time that it isn't
> even meassurable but so I'm told there are exceptions.

I think it's often done for software-portability reasons; sometimes
because some hardware works both ways but has some irritating flaw in
its less-favoured organisation.

System software (kernels, libraries) tends to work both ways, because
it's written by people who thought about it.  Huge applications which
have only ever run on x86 and friends often don't work.

Finding the problems faster is a counsel of perfection: in practice, a
lot of us just want something that works, tomorrow.

Swapping probably is an unmeasurable load: even if it takes 8-10
instructions per word on a 500MHz CPU that's 200Mbytes/s.  But it is
ugly, particularly when it's required to restore correct byte sequence
because of a naive hardware interface (one, for example, which
connects the MIPS CPU data lines to the same-numbered PCI ones...)

So there are arguments on both sides, and players in both camps.  I
believe it's too late to corral all MIPS/Linux activity into one
endianness or the other.

Embrace bi-endianness!

-- 
Dominic Sweetman, 
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk