Endianness
Byte order
One of the special features of the MIPS architecture is that all processors except the R8000 can be configured to run either in big or in little endian mode. Byte order means the way the processor stores multibyte numbers in memory. Big endian machines store the byte with the highest value digits at the lowest address while little endian machines store it at the highest address. Think of it as writing multi-digit numbers from left to right or vice versa.
Programmers probably already know what all this is about. For non-programmers it's of interest because it makes a difference when downloading software packages or compiling and configuring software.
RPM Package Names
MIPS binary rpm packages have a suffix of .mips.rpm for big endian and a suffix of .mipsel.rpm for little endian packages. Very old big endian packages used to use .mipseb.rpm. Just to make things even more complicated even older big endian packages used to use .mips.rpm suffix also, that is the naming convention was changed and changed back again somewhat later.
GNU Configuration Names
Some packages take a GNU-style name as argument. For big endian this is mips-linux, for little endian mipsel-linux. This assumes 32-bit. For 64-bit that would be mips64-linux for big endian rsp. on little endian mips64el-linux.
Bi-endian Systems
So, you have a bi-endian system, that is a system that can be configured to either big endian or little endian byteorder. What is the preferable byteorder? The answer to this question has been the reason for many flamewars yet no answer has been found yet.
- Frequently reason to choose a particular byteorder is having gotten used to a particular byteorder when developping for a particular architecture.
- Performance is very rarely a reason. The overhead from endianness swapping in software rarely shows up in benchmarks at all. If it does, the latest versions of the MIPS architecture, MIPS32 V2.0 and MIPS64 V2.0 optimize this.
- If software portability is desired during development using the opposite endianness of external data structures is a good choice; it'll make bugs show up faster. For example network byte order is big endian so developing code on a little endian system may help to flesh out endianness bugs immediately. Or if on disk data is little endian, a big endian system can help achieving the same purpose.
- On rare opportunities code for the one endianness tends to be shorter than for the other. Most code is endianness agnostic, so for a typical application the difference is probably a few bytes only and little endian tend to have a tiny advantage more often.
- Big endian code tends to trigger certain types of bugs more agressivly.
- Little endian is the natural method of representing large bitfields. By defining bitfields as arrays of bytes this can be achieved with no overhead at all on big endian systems also.
- On 64-bit the big vs. little endian ratio is rather very large in favor of big endianness.
- On 32-bit kernels there seems to be somewhat a majority of big endian systems. Distribution download figures suggset approximately a 60:40 ratio.
- It seems every vendor has their favorite endianness.
