Subject: Mixed byte order; Was: IMPORTANT: MACHINE_ARCH WRONG ON MIPS PLATFORMS
To: ws@tools.de, Warner Losh <imp@village.org>
From: Andrew Cagney <cagney@tpgi.com.au>
List: tech-toolchain
Date: 07/24/1998 13:39:56
Excerpts from mail: 23-Jul-98 Re: IMPORTANT: MACHINE_ARCH.. Warner
Losh@village.org (666)

> In message <199807231750.TAA17410@kurt.tools.de> Wolfgang Solfrank writes:
> : Correct me if I'm wrong, but isn't the endianess on mips a hardware feature,
> : i.e. wired by motherboard logic?

> You are wrong :-).  At least the R4000 (and I think the R3000) have a
> bit that says "run in the opposite mode" which allows one to run
> userland big endian binaries on a little endian machine.  This feature
> was put in place for DEC, iirc, because they had to run some big
> endian binaries on their ulrix boxes (little endian) for something or
> another.

> It is true that you need to boot a specific kernel for the motherbaord
> that is either big endian or little endian.

Your both half right :-)  (Wolfgang, the more recent MIPS processors are
just like the PPC)

A simplistic summary is to say:

Mixed-endian hardware can be implemented two ways:

	o	 the right way

	o	 the wrong way

Both MIPS and PPC implemented it the wrong way.


The wrong way?

Consider a data bus that is 8 bytes wide.  In BE mode, the byte at
address 0 is in the left most byte lane while in LE mode it is in the
right most byte lane (or vice-versa).

The consequence is that this technique renders it impossible to
efficiently implement mixed-endian support - BE binary running on LE
OS/HW.


The right way?

Consider that 8 byte wide data bus again. Regardless of the endian mode,
the byte at address 0 always appears in that left most byte lane.


	enjoy,
		Andrew

PS: If any one is interested I've got a worked example somewhere ....