Little or big endian?

[Basic]

When integers are stored in memory they can be stored in different ways. The two main orders are:
Least significant byte on lowest adress: little endian (intel)
Most significant byte on lowest adress: big endian (680x0)

If you use one processor, you're pretty much forced to use the native format. But if you're not bound by such things, what's your preference? What format is the most "beautiful"?

(I have a strong opinion, but I know that there are others that have equaly strong opinion in the other way.)

Try to not lock yourself into thoughts like "I like processor X better than processor Y, so I'll take that endianness".

 

[Captain Chickenpants]

If you have to look at memory then it is much easier to use a big endian system as the bytes are ordered as you would read them naturally.

So my vote goes to big endian, not sure that it is beautiful, but it is a bit more friendly.
CC

 

[Simon F]

I used to like big endianess when I used to do some hacking on my old 68000 (Mac), but when I started with Transputers I saw the sense of little endianess.

 

[Simon F]

If you have to look at memory then it is much easier to use a big endian system as the bytes are ordered as you would read them naturally.

So my vote goes to big endian, not sure that it is beautiful, but it is a bit more friendly.
CC

But Paul, when you actually do programming, it's much nicer (i.e consistent!!!!) with little endian.

When integers are stored in memory they can be stored in different ways. The two main orders are:
Least significant byte on lowest adress: little endian (intel)
Most significant byte on lowest adress: big endian (680x0)

At Uni, the first lot of assembly language programming we did was on a PDP10, which has a 36bit word - you can't have byte endianess issues

 

[Xmas]

On the one hand, when reading numbers like in a hex-dump I certainly prefer big endian because of the way we write numbers, most significant digit to the left (and left implying lower address because of our left-to-right writing).
Also, it's a bit confusing when 0x12345678 is ordered differently than { 0x12, 0x34, 0x56, 0x78 }.

On the other hand, IMO it feels "natural" to increment the address by one to get the next higher byte.

I don't really prefer one over the other, but then again I don't have to care about it very often.

 

[pcchen]

I know the sense of little endian (actually I rarely used a big endian computer). However, when I write variable length coding for numbers, I tend to use big endian. I don't know why.

 

[Simon F]

I don't really prefer one over the other, but then again I don't have to care about it very often.

Haven't you ever tried reading/writing a binary file made up of bytes/integers/RGBA pixels etc? I generally have code that has to run on various architectures and not checking for the endianess can cause a disaster!

 

[K.I.L.E.R]

1 little... 2 little... 3 little indians...

What are we talking about again? :?
Big Indians or little Indians? Hmmm...

What's the story?

Memory addys eh?

You can store as 640x0 or 0x640?
Or am I smoking something hallucinogenic?

 

[Ilfirin]

Big endian for logic reasons, but I would be just as happy if everyone switched to little endian. All I really care about is having one consistent system across all platforms, but who knows when/if that will happen.

 

[pascal]

I have programmed x86 and 68000 and big endian feels more "natural". It is more about how you feel better.

Maybe someone from Japan or China will have a different felling.

 

[Xmas]

I don't really prefer one over the other, but then again I don't have to care about it very often.

Haven't you ever tried reading/writing a binary file made up of bytes/integers/RGBA pixels etc? I generally have code that has to run on various architectures and not checking for the endianess can cause a disaster!

I didn't have to worry about portability so far. And as long as you treat your datatypes as what they are, you only can get problems on the data input/exchange part.

btw, what's the problem with RGBA pixels? If you have 32bpp, the byte order is well-defined by the image file format. No issues with endian type here, because you have four ordered bytes, not one int.

 

[Simon F]

I have programmed x86 and 68000 and big endian feels more "natural". It is more about how you feel better.

So assume we have: (assume that char/short/long == 8/16/32)

typedef unsigned char U8;
typedef unsigned short U16;
typedef unsigned long   U32;
typedef union
{
   U8    A[4];
   U16   B[2];
   U32   C;

}Value;

Value BigNum[2];
U8 *pU8;

BigNum[0].C = LeastSigWord;
BigNum[1].C = MostSigWord;

what's more natural?...

// Divide by 256... (it's a bit contrived but (and, yes, shifts and masks may be faster)....)

pU8 = BigNum[0].A;

for(i = 0; i < 7; i++, pU8++)
{
   pU8[0] = pU8[1];
}
*pU8 = 0;

or

// Divide by 256... 
Oh forget it... it's time to go home

 

[Simon F]

btw, what's the problem with RGBA pixels? If you have 32bpp, the byte order is well-defined by the image file format. No issues with endian type here, because you have four ordered bytes, not one int.

I usually use shifts etc on longs when manipulating ARGB

 

[pascal]

Simon, I understand what you say
I think I should have said I programmed the assembly (not C) of this processors long time ago (from 86 to 90), then we have different views.

 

[JohnH]

I think you often end up with a correlation between those that regularily mess with HW at the lowest level and a preference for little endian. Basically little endian provides data ordering which is word sized invariant, big endian doesn't. This can cause huge problems, for example, express a control word for HW which might be fed down a channel that doesn't match the size of the control word (think serial bus used to program regsiters). Anyone whos designed HW that needs to run on both will know what I mean. And then there's the problem of who's big endian you're talking about, only little endian is consistent across all implementations...

John.

 

[Xmas]

btw, what's the problem with RGBA pixels? If you have 32bpp, the byte order is well-defined by the image file format. No issues with endian type here, because you have four ordered bytes, not one int.

I usually use shifts etc on longs when manipulating ARGB

IMO using bytes here is much simpler. There are few operations you can do on all channels at once (operating on a long), and even then not all of them are affected by endian type.

 

[Basic]

Hey, you're voting for the wrong option!
My preference is definitely for little endian.

You've mentioned the two big arguments:
Big endian looks best in a memory dump.
Little endian is more natural in the sense that least significant byte is stored at lowest adress. (Just as bits in a byte are numbered with lowest number for the least significant bit.)

Little endian makes the code more elegant if it's explicitly dealing with multi-byte(word) integers. And my argument for little endian is that the resulting code is what have to run all the time, while memory dumps usually are just for (low level) debugging. The final code is the most important to me.


(And then if you add that most processors are little endian, it's IMHO a no brainer to make everything you can into little endian.)

PS
You may have guessed that I've just suffered from endian-swapping-code-writing. Just because someone defined some interfaces to be big endian (because it looks better in dumps). The only reason to look at dumps of those interfaces is probably to check that the endian-swapping was done right.

PPS
Simon:
And PDP10 isn't the only one. The ASIC team I've been in has done several application specific RISC processors, and we've got both non-power-of-2 and non-divisable-by-8 word bitlengths in them.

 

[arjan de lumens]

Aside from just the esthetic issues: coding multiprecision math libraries tends to be qute a bit nicer/easier with little-endian that with big-endian, whereas sorting strings may benefit from big-endian arithmetic.

Myself? Grown up with little-endian, come to just think of it as default and big-endian as a bit .. odd.

 

[epicstruggle]

big endian all the way.
later,

 

[Colourless]

Little endian for sure

Why? Because things like this produce expected results, even though they are usually pointer hacks:

union 
{ 
    char    byte;
    short   word;
    long    dword;
} value; 

value.dword = 100;

After that, each member of the union will be '100' as little endian. But as big endian, only dword would be 100, byte and word would both be 0.

Of course it all comes down to if you want more accuracy (big endian) or a bigger dyanmic range (little endian) when you add extra bytes.