- I was wondering if endianness only depends on CPU?
- Does it depends on other hardware, such as memory, secondary storage device?
- Does it depends on OS? Why in Wikipedia, does it seem to be true?
Endianness is about numeric data when a number is too big to fit in one byte. E.g. ASCII text is just bytes in a row, not concerned by endianness.
If we put a small number like 42 in a 32-bit (4 byte) integer, we see that with big endian (BE) just the last byte is used and with little endian (LE) just the first byte is used:
| | byte | byte | byte | byte | |----+---------+---------+---------+---------| | BE | 0 | 0 | 0 | 42 | | LE | 42 | 0 | 0 | 0 |
Architecture endianness is the CPU endianness. RAM doesn't do math so it doesn't care.
Devices like sound cards do care (e.g. 16bit 44100kHz audio is mostly BE), but it's Operating System's (device driver) responsibility to tell CPU to maybe convert the endianness before sending to sound card.
In networks, mostly everything is big endian, so OS has to tell little endian processors to byte swap integers as network packets are constructed.
File systems come in both endiannesses. E.g. FAT32 is LE so only BE-architectures have to do byte swapping when using FAT32.
In C network programming you have to remember to use
ntohl() -functions to convert between host- (native) and network byte order. When the program is compiled on a big endian system, the functions do nothing. On little endian systems they swap byte order.
Architecture endianness is a byte level thing. Order/numbering of bits is mostly irrelevant when considering architecture endianness. BUT it's always nice to know :)
Roughly LSB (Least Significant Bit) first is the LE of bit world and MSB (Most Significant Bit) first is the BE of bit world.
Most CPU and serial busses seem to be (surprisingly) LSB even on big endian systems such as SPARC. Also Ethernet is LSB despite bytes mostly go in big endian order. On the other hand e.g. PPC is big endian and MSB first.
CPU controls the endianness. A few CPUs can switch between big-endian and little-endian. x86/amd64 architectures don't possess this feature.
Endianness is an implicit thing with load and store instructions on the CPU. Data that will not fit in one byte (0-255) needs to be read and written in a series of multiple bytes, and obviously those bytes need to be read and written in a consistent order. The designers of the CPU also have to choose an order that the bytes of registers are read from and written to. The order isn't important if the data never leaves the CPU or RAM, but when you get into things like writing data to I/O registers (which might not expect the same order) and disk sectors (where other systems might read the data) it then becomes important and an external standard is needed. This standard is usually part of the hardware spec or a file format specification. Any programmer/design worth his salt is going to design persistence formats to take this into account, bad programming or programming that has assumed things will always be read on a single architecture can reveal a fault.
An OS deals heavily with I/O registers and disk sectors so #2 applies here. One particularly important area that needs a common standard between all CPUs is implementations of filesystems. That is why there are separate
mipselbuilds of Debian and what not.
Endianness is simple the order which the processor puts the bits of a binary number. The RAM doesn't care in what order data is saved to it, nor does the hard drive (since they take no action on the contents of the datastream themselves, just carry out directives from the processor/chipset on where to put it.) Operating Systems can be built to work with both endiannesses (Mac OS X for example.)
Endianness doesn't necessarily depends on the CPU. For example Ethernet and most of the TCP/IP low level protocols are big endian, regardless of the CPU and hopefully, x86 based machines can still connect to the Internet. Similarily, OSes running on a big endian CPU will read FAT32 which little endian file system or use little endian PCI cards, and so on.