endianness

Why are both little- and big-endian still in use today , after ~40 years of binary computer-science? Are there algorithms or storage formats that work better with one and much worse with the other? Wouldn't it be better if we all switched to one and stick with it? When adding two numbers (on paper or in a machine), you start with the least significant digits and work towards the most significant digits. (Same goes for many other operations). On the Intel 8088, which had 16-bit registers but an 8-bit data bus, being little-endian allowed such instructions to start operation after the first

I'm reading "Learning Core Audio: A Hands-On Guide to Audio Programming for Mac and iOS" by Chris Adamson and at one point the author describes big-endian as: the high bits of a byte or word are numerically more significant than the lower ones. However, until now I though the problem of big-little endian only applies to byte order and not bit order. One byte has the same bit order (left to right) no matter if we're talking about little endian or big endian systems. Am I wrong? Is the author wrong? Or did I misunderstood his point? Since you can't normally address the bits within a byte

An intern who works with me showed me an exam he had taken in computer science about endianness issues. There was a question that showed an ASCII string "My-Pizza", and the student had to show how that string would be represented in memory on a little endian computer. Of course, this sounds like a trick question because ASCII strings are not affected by endian issues. But shockingly, the intern claims his professor insists that the string would be represented as: P-yM azzi I know this can't be right. There is no way an ASCII string would be represented like that on any machine. But apparently,

Endianness from what I understand, is when the bytes that compose a multibyte word differ in their order, at least in the most typical case. So that an 16-bit integer may be stored as either 0xHHLL or 0xLLHH . Assuming I don't have that wrong, what I would like to know is when does Endianness become a major factor when sending information between two computers where the Endian may or may not be different. If I transmit a short integer of 1, in the form of a char array and with no correction, is it received and interpretted as 256? If I decompose and recompose the short integer using the

Below is my code that replaces the DataInputStream to wrap an InputStream, but provides extra methods to read little endian data types in addition to the normal methods that read big endian types. Feel free to use it if you'd like. I have a few reservations as follows. Notice the methods that do not change functionality (the functions that read big endian types). There is no way I could implement the DataInputStream as the base class and use its methods, like read(), readInt(), readChar(), etc? My class hierarchy seems a little odd here. Is this appropriate? Do any of these other types like

I have a byte array where the data in the array is actually short data. The bytes are ordered in little endian: 3, 1, -48, 0, -15, 0, 36, 1 Which when converted to short values results in: 259, 208, 241, 292 Is there a simple way in Java to convert the byte values to their corresponding short values? I can write a loop that just takes every high byte and shift it by 8 bits and OR it with its low byte, but that has a performance hit. With java.nio.ByteBuffer you may specify the endianness you want: order() . ByteBuffer have methods to extract data as byte, char, getShort() , getInt() , long,

How do I convert big endian to little endian in ARM? old_timer Are you talking about ARM's endian modes, or reading something written by some other big endian processor, etc? Normally converting to/from big/little endian you swap the bytes around. So 0xABCD is 0xCDAB when viewed as a 16 bit number 0x12345678 is 0x78563412 when viewed as a 32 bit number. ARM cores armv5 and older (ARM7, ARM9, etc) have an endian mode known as BE-32, meaning big endian word invariant. armv6 and newer (mpcore, cortex-somethings) have BE-8, or big endian byte invariant. So if you are using an armv4 for example in

I want to read sizeof(int) bytes from a char* array. a) In what scenario's do we need to worry if endianness needs to be checked? b) How would you read the first 4 bytes either taking endianness into consideration or not. EDIT : The sizeof(int) bytes that I have read needs to be compared with an integer value. What is the best approach to go about this problem Do you mean something like that?: char* a; int i; memcpy(&i, a, sizeof(i)); You only have to worry about endianess if the source of the data is from a different platform, like a device. a) You only need to worry about "endianness" (i.e.,