Endianess - Revision history

Ralf: /* Bi-endian Systems */

2006-06-08T16:42:50Z

‎Bi-endian Systems

Ralf: Make R8000 a link.

2006-05-17T11:44:07Z

Make R8000 a link.

Ziswiler: /* Bi-endian Systems */

2005-12-23T22:48:23Z

‎Bi-endian Systems

Ralf: Blarg.

2005-07-04T12:34:58Z

Blarg.

Ralf: /* Bi-endian Systems */

2005-07-04T12:33:45Z

‎Bi-endian Systems

Ralf at 13:43, 2 January 2005

2005-01-02T13:43:45Z

Ralf at 05:13, 6 November 2004

2004-11-06T05:13:17Z

Ralf at 12:56, 5 November 2004

2004-11-05T12:56:40Z

New page

== External Links ==
* [http://en.wikipedia.org/wiki/Endianess Wikipedia article on Endianess]

@@ Line 20: / Line 20: @@
 * 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.
 == External Links ==
 * [http://en.wikipedia.org/wiki/Endianess Wikipedia article on Endianess]

@@ Line 1: / Line 1: @@
 == 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.
+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.

@@ Line 15: / Line 15: @@
 * 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 endianess swapping in software rarely shows up in benchmarks at all.  If it does, the latest versions of the MIPS architecture, [[Instruction_Set_Architecture#MIPS32_V2.0_and_MIPS64_V2.0|MIPS32 V2.0 and MIPS64 V2.0]] and optimize this.
+* Performance is ''very'' rarely a reason.  The overhead from endianess swapping in software rarely shows up in benchmarks at all.  If it does, the latest versions of the MIPS architecture, [[Instruction_Set_Architecture#MIPS32_V2.0_and_MIPS64_V2.0|MIPS32 V2.0 and MIPS64 V2.0]] optimize this.
 * If software portability is desired during development using the opposite endianess 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 endianess 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 endianess tends to be shorter than for the other.  Most code is endianess 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.

@@ Line 20: / Line 20: @@
 * 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.
 == External Links ==
 * [http://en.wikipedia.org/wiki/Endianess Wikipedia article on Endianess]

@@ Line 20: / Line 20: @@
 * 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.
 == External Links ==
 * [http://en.wikipedia.org/wiki/Endianess Wikipedia article on Endianess]

← Older revision		Revision as of 05:13, 6 November 2004
Line 1:		Line 1:
		+	== 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 endianess swapping in software rarely shows up in benchmarks at all. If it does, the latest versions of the MIPS architecture, [[ISA\|MIPS32 V2.0]] and [[ISA\|MIPS64 V2.0]] optimize this.
		+	* If software portability is desired during development using the opposite endianess 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 endianess 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 endianess tends to be shorter than for the other. Most code is endianess 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.
		+
	== External Links ==		== External Links ==
	* [http://en.wikipedia.org/wiki/Endianess Wikipedia article on Endianess]		* [http://en.wikipedia.org/wiki/Endianess Wikipedia article on Endianess]