Subject: Mixed byte order; Was: IMPORTANT: MACHINE_ARCH WRONG ON MIPS PLATFORMS
To: firstname.lastname@example.org, Warner Losh <email@example.com>
From: Andrew Cagney <firstname.lastname@example.org>
Date: 07/24/1998 13:39:56
Excerpts from mail: 23-Jul-98 Re: IMPORTANT: MACHINE_ARCH.. Warner
> 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
> 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
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.
PS: If any one is interested I've got a worked example somewhere ....