I use a Intel processor to write this text, and this processor is is using Little Endian for the byte order. This is about Endian, not Indian :-).
Many processors I have programmed were Big Endians. With the addition of Freescale Kinetis (an ARM Cortex M4) and DSC in MCU10.2, I have a daily mixture with Big Endian (S08, ColdFire, …) and Little Endian (DSC and Kinetis).
And the ‘war’ still seems to rage on: not only between the silicon designers, but as well between the software geeks. Standardization is a good thing, but sometimes there might not be a single way to do things: as you can break an egg from the ‘big’ or from the ‘little’ end. Well, as long as you know what you are doing and the consequences of it, that will be fine. And it keeps our world interesting ;-). One interesting thing is that some processors allow switching the endianess, PowerPC as an example.
I admit: In my mindset I feel I’m more attached to the big endian view of the world. But it is just a view. The good thing is: eclipse can view it from both sides (with a view :-)) as outlined in Memory is Everything, using the Memory Browser view:
Eclipse and MCU10 does a good job hiding the endianess from the user. Still, there are places where you can see what is behind: If you open the Project Explorer View and inspect the binary file, you will see either a ‘be’ for Big Endian or ‘le’ for Little Endian.
The ‘be’ or ‘le’ information in the Project Explorer view comes from an attribute in the ELF file which tells the reader if the architecture is either little or big endian.
From the software side I try not to think about the endianess. But it is a reality, and writing code portable between the two views (or implementation) of the world is truly challenging.
Happy egg breaking 🙂