Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
  1. I was wondering if endianness only depends on CPU?
  2. Does it depends on other hardware, such as memory, secondary storage device?
  3. Does it depends on OS? Why in Wikipedia, does it seem to be true?
share|improve this question
    
I know very little about this, but from reading the very article you link to, I gather: 1. Not on bi-endian systems, otherwise, yes. 2. Not CPU endianness, as they don't need to actually modify the data they hold. See the section on file and byte swap for related issues 3. Yes, for bi-endian architectures. Someone has to decide. –  Daniel Beck Jul 8 '11 at 20:45
    
@Daniel: Thanks! What do you mean by "Not CPU endianness"? –  Tim Jul 8 '11 at 21:02
1  
Other hardware might need to be aware of endianness issues (networking is mentioned in the article). That's why I tried to distinguish the kind you refer to by calling it "CPU endianness". –  Daniel Beck Jul 8 '11 at 21:09
    
One should maybe add that some CPUs (e.g. PowerPC) support both endianess. They start in a default, but it can be switched. –  flolo Jul 9 '11 at 6:03
add comment

4 Answers 4

up vote 8 down vote accepted

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[0] | byte[1] | byte[2] | byte[3] |
|----+---------+---------+---------+---------|
| 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 htonl() and 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.

share|improve this answer
add comment

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.)

share|improve this answer
add comment
  1. CPU controls the endianness. A few CPUs can switch between big-endian and little-endian. x86/amd64 architectures don't possess this feature.

  2. 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.

  3. 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 mips and mipsel builds of Debian and what not.

share|improve this answer
1  
"Data that will not fit in more than 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." - I don't think that you want that more in there. –  EBGreen Jul 8 '11 at 21:24
    
Thanks! in 2, does "register" in "The designers of the CPU also have to choose an order that the bytes of registers are read from and written to" same as "I/O register" in "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"? –  Tim Jul 8 '11 at 21:25
    
@Tim, For the purposes of this discussion I would say yes. –  ultrasawblade Jul 8 '11 at 21:51
1  
See @jkj's answer. He distilled the essence of what I was trying say a bit more clearly. –  ultrasawblade Jul 9 '11 at 0:36
1  
@ultrasawblade ok I see you have answered that problem here superuser.com/questions/308487/… You pretty much say I/O Registers are in the device, not the processor. Fine. Nothing controversial there then. –  barlop Jul 10 '11 at 17:18
show 2 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.