[Top] [All Lists]

Re: Why is byteorder removed from /proc/cpuinfo?

To: Ralf Baechle <>
Subject: Re: Why is byteorder removed from /proc/cpuinfo?
From: Dominic Sweetman <>
Date: Mon, 10 Dec 2001 18:40:00 +0000 (GMT)
Cc: "H . J . Lu" <>,
In-reply-to: <>
References: <> <>
Ralf Baechle ( writes:

> (endianess should be considered per _thread_ on MIPS!)

I tried to ignore this, but I can't.  Ralf, what an elegant idea, but
it really doesn't make much sense.  

Ralf is influenced, I think, by the fact that MIPS CPUs have two
endianness switches: a "one-time" select which needs to match some of
the rest of the hardware in your system, and is picked at reset time,
and the very dodgy status register 'RE' bit.  RE ("reverse endianness
in user mode") bit was invented in a fit of madness for the MIPS
R4000.  It was intended to make it possible to run binaries from the
little-endian DECstation on a big-endian MIPS unix system.  As far as
I know, nobody ever did the software work to make such a thing happen,
so nobody really ever found out if it would have worked.

So yes, you could try to change the RE bit between threads... but
threads generally expect to be able to share code and data.  Now:

1. MIPS code is endianness-dependent (your big- and little-endian
   threads would require separate copies of any library function, for

2. MIPS data is endianness-dependent.  The endianness-switch uses
   cheap and simple hardware and produces particularly nasty effects.
   That's OK when you are just doing a one-time select (effectively,
   the memory system inherits the CPU's endianness, hiding the

   But a big-endian and little-endian thread sharing data will see
   everything mangled; in fact they'll only show mutual comprehension
   of data consisting of aligned words (either 32-bit or 64-bit,
   according to the underlying CPU).  A feature which allows you to
   tell whether you've got a 64-bit CPU while running 32-bit code is
   not good.

3. The one-time endianness switch also controls some peripheral (chip
   interface) logic.  The memory controller has to know the CPU's
   endianness to decode bus cycles, so the RE bit presumably must
   leave this alone: though on the original R4000 it happened that it
   didn't matter so long as the backward code stayed in cache...  be
   that as it may, it means this whole thing is even more broken for
   64-bit CPUs on a 32-bit bus, for example.


a) Any MIPS system really does have an endianness: the kernel always
   runs in it.  Since the kernel binary is already committed to either
   big- or little-endian, it really is fairly appropriate to have a
   compile-time flag to say which.

b) Dynamic endianness is just plausible on a unix process basis
   (thread + address space), as originally planned: but the amount of
   kernel re-writing involved, plus a complete second set of dynamic
   libraries, plus endless problem in I/O make it easy to see why it
   never got done.

   Dynamic endianness on a per-thread basis would require fantasy
   hardware which operates differently from the way MIPS chips do...

Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032

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