Page 1 of 1

Let's get really esoteric: big-endian or little-endian?

Posted: Fri Nov 16, 2007 2:35 am UTC
by photosinensis
Personally, I cannot understand those damned Liliputians with their little-endian x86 processors. I think they're just incredibly stupid and inane.

Let us all crack our eggs and encode our numbers from the big end forever!

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Nov 16, 2007 3:13 am UTC
by Goplat
Little-endian is obviously superior. It is more logical, as the low bits exist at low addresses and the high bits at high addresses; the bit with a value of 2^n exists is part of the byte at base address +n/8, instead of +3-(n/8) or +7-(n/8) or whatever. It also allows for faster downward typecasting for indirect variables. If p is the address of a 32-bit value but you only want 16 bits, on a little-endian processor you can just use p as-is, while on a big-endian processor you have to add 2 first with the associated performance penalty.

The only argument in favor of big-endian are that it's the way numbers are usually written, but if that's what we're going by shouldn't computers be using decimal arithmetic instead of binary?

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Nov 16, 2007 4:21 am UTC
by phlip
Absolutely, little-endian is superior. To use big-endian machines is to bring into computing, that logical paragon, the illogical and inconsistent English writing style. Namely that text is written from left-to-right (character 0 is the farthest left, character 1 is to the right of that) but numbers are right-to-left (the digit for 100 is the farthest right, 101 is to the left of that).

There is no need for this inconsistent behavior to infect the computing world... let's keep our computers pure.

Authorized by phlip, for the Logic Is Paramount Party, Canberra

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Nov 23, 2007 7:42 pm UTC
by Yakk
You can always get 16 bits out of a 32 bit number.

Which 16 bits you get differs between little-endian and bit-endian. Do you want the high end or low end bits?

And getting the mod 2^16 of a number seems like a rather silly and numerically unstable step to take. At least dividing by 2^16 is stable.

Practically, I care very little. I do see the advantage of being able to read computer memory easier as a plus (are there any societies that don't use arabic numerals?)

Having the two different convetions is rather annoying, however. It would be as if you had a language where there where pointers that pointed to the end of a block of memory, and others that pointed to the beginning -- sure, the two are equivalent, but it is really annoying to have to switch between the two!

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 4:36 am UTC
by Anpheus
Big-endian is what I think it ought to be, because it just doesn't make sense that we count differently for bits than we do for bytes!

Nevertheless, as long as the compiler or CPU I'm working with doesn't care (after all, when I perform a << or >> op, it doesn't affect the actual order of bits) then it doesn't matter.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 4:52 am UTC
by phlip
Anpheus wrote:Big-endian is what I think it ought to be, because it just doesn't make sense that we count differently for bits than we do for bytes!

Huh? Bit 0 is the least-significant bit. This at least isn't in dispute, there's actually a standard here... 1<<n sets bit n. Why would making Byte 0 the MSB be consistent with that?

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 5:09 am UTC
by Anpheus
Bit 0 is the least significant bit if you count from right to left, but not left to right.

The method of arabic numerals makes sense, express the most significant information first, least significant last.

If you have bytes like this in order of increasing memory address: 0x03 | 0x02 | 0x01 | 0x00

Little endian: the byte value 0x03 is the least significant, whereas byte value 0x00 is the most significant. This is 'least important value first.'
Big endian: the byte value 0x03 is the most significant, whereas the byte value 0x00 is the least significant. This is 'most important value first.'

In an intel processor, byte ordering is little endian. However, bit order is big endian, in the byte:
11110000
The value is interpreted 'most important first' or 'biggest first' or 'big-endian.' That is, the 1111 has a greater affect on the integer value than the 0000 (even if the 0000 were all 1's.)

Edit: I did some looking around and I actually can't find a concrete source for that anywhere. I was always under the impression, probably due to the sheer number of introductions to binary arithmetic, that nearly every processor uses a big-endian bit order, and that x86 does a little-endian byte order. Another reason for that belief is the << operator literally shifting left the bits. Does it actually perform a left shift or a right shift in the x86 ISA? Are the << and >> operators facing the wrong way?

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 5:29 am UTC
by phlip
The terms "left" and "right" make little sense when talking about the actual architecture... who knows how the registers are laid out on the chip? (Rhetorical question... of course there's some Intel/AMD engineers who know.) Byte-order makes a difference on the architecture because you can address a single byte, or address a bunch of bytes together as a word... so you have to know how it internally arranges those bytes to make that word. However, the bits aren't individually addressable... there are operators for things like binary &, and left/right shifts, but they don't depend on how the bits are actually arranged.

Bit 0 is the least-significant bit by convention... it's not an architecture-dependent term. Ditto left/right shift... there the convention relates to our conventional way of writing numbers... not the internal workings of the CPU.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 6:05 am UTC
by Anpheus
Actually it isn't a silly question. AFAIK both x86 and PowerPC use the same bit order, but a different byte-order. This makes converting binary format files from one to the other a lot simpler, any multi-byte integer or POD needs only its bytes flipped reversed, but no bit swapping is necessary.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 8:57 am UTC
by Infornographer

Code: Select all

ADD EAX, EBX
MOV [EAX], ECX

Oh look I totally didn't have to BSWAP ECX. :p

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 9:19 am UTC
by Anpheus
I don't get the point of your post?

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 9:23 am UTC
by Infornographer
Anpheus wrote:I don't get the point of your post?


Probably for the better. It didn't exactly have any intellectually substantial content. I just have very bad memories of forgetting to BSWAP when working in a big-endian format. :/. I think little-endian makes more sense, but even if it didn't, I think, like QWERTY, it may just never die because people always used it as a standard.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 6:11 pm UTC
by xyzzy
On Holy Wars and a Plea for Peace

This was done to death years ago.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Dec 01, 2007 8:38 pm UTC
by adlaiff6
I had an assembly professor tell me there was no way to programmatically determine in assembly (MIPS) if the machine you were on was little-endian or big-endian.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sun Dec 02, 2007 1:04 am UTC
by Anpheus
He's wrong. In MIPS you load can load a word at any address, but ints are written at a multiple of 4 bytes.

To test whether or not you have little-endian or big-endian:

Imagine starting out with an undefined state at addresses 0 to word_size-1:

Code: Select all

Address:   0 1 2 3 4 5 6 7
Data   :  ????????????????

Store 0x00FF (255) into whatever your word size is, at address 0 and the following word_size-1 bytes.

Code: Select all

Address:   0 1 2 3  4 5 6 7
Data LE:  FF000000 ????????
Data BE:  000000FF ????????

Store 0x0000 into address word_size (4 or 8, usually.)

Code: Select all

Address:   0 1 2 3  4 5 6 7
Data LE:  FF000000 00000000
Data BE:  000000FF 00000000

Load a word at address 1 (the 1st byte.)

Code: Select all

Address:   0     1 2 3  4    5 6 7
Data LE:  FF |  000000 00 | 000000
Data BE:  00 |  0000FF 00 | 000000
LE Integer: 0
BE Integer: 65280


This is just one of many similar, nearly identical ways of determining byte order.

Bit order however, is truly impossible to determine without examining the hard drive's content. And it might even be true that the driver or the hard drive uses its own arbitrary scheme, in which case, the only way to determine bit order is to consult someone who actually builds these chips.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sun Dec 02, 2007 9:24 pm UTC
by adlaiff6
She is wrong, yes. What I told her then was approximately the same thing you wrote.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Mon Dec 10, 2007 6:43 pm UTC
by evilbeanfiend
bah you are all infidels! middle-endian is the way to go! http://en.wikipedia.org/wiki/Endianness#Middle_Endian

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Tue Dec 11, 2007 12:29 am UTC
by Goplat
There are some weird CPU architectures that won't let you read or write unaligned words. But you can always determine byte-order by writing a word and reading back bytes, or by writing bytes and reading back a word. (If there is no way to read or write individual bytes, then byte-order is meaningless.)

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Wed Feb 20, 2008 1:16 am UTC
by Aperfectring
It has to be big-endian. Main reason: network byte order. The standard for transmitting data over a wire is big-endian. If we are to all use one standard for byte order, then removing the htonl and ntohl statements in network programming should be part of said goal. The only way that is going to happen, is if we all agree that we are going to accept the current network standard as the CPU standard.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Apr 24, 2009 10:31 am UTC
by Kisama
Little-endian makes sense to me because it means that the least-significant bit, nibble, byte and word all have the same address. Since the least-significant bit is bit 0, then by extension the least-significant byte should also be byte 0 and in bit-addressable memory, bit 0 of byte 0 should be at address 0.

Goplat wrote:It is more logical, as the low bits exist at low addresses and the high bits at high addresses;

Yeah, like that.

Observe:
binary: 1010100001001011 (2^15 digit (bit 15) .... 2^0 digit (bit 0))
decimal: 43083 (10^4 digit .... 10^0 digit)
hexadecimal: A84B (16^3 digit (nibble 3) .... 16^0 digit (nibble 0))

This all makes sense and remains consistent with changes of base. Consider that the word "index" in English can be used to mean "exponent" as well as to mean "position in a list" (the "address" of the list item.) In base b, digit number n with symbolic value x has an actual value of x * b^n. Here, n is the "address" of that digit, and is also the exponent of b. This is a little-endian system which all works nice and neatly and consistently.
Now, the big-endians screw all the neatness up. By storing bytes in reverse order the direction of base-256 numbers is effectively reversed, with confusing repercussions for all other bases.

With big-endian foolishness:
binary: 01001011 10101000 (2^7 digit ... 2^0 digit, 2^15 digit ... 2^8 digit)
decimal: Can't even represent it but that's ok because computers don't count on their fingers.
hexadecimal: 4B A8 (16^1 digit, 16^0 digit, 16^3 digit, 16^2 digit)

Anything other than little-endian storage is actually kind of arbitrary: Swapping the byte order has different results than swapping the order of 16-bit words or 32-bit words, or even 4-bit words. Little-endian is the only way that makes sense because the order of the digits stored remains the same no matter what base you use, no matter what word-size you use, no matter what unit of data is addressable. Big-endian reverses the byte-order but then the nibbles and octets and bits no longer have a sensible order to them.

phlip wrote: However, the bits aren't individually addressable... there are operators for things like binary &, and left/right shifts, but they don't depend on how the bits are actually arranged.

Bit 0 is the least-significant bit by convention... it's not an architecture-dependent term. Ditto left/right shift... there the convention relates to our conventional way of writing numbers... not the internal workings of the CPU.

I believe that in some cases bits are individually addressable. I seem to recall using "SBI PORTx, n" to set bit n of i/o port x on AVR micros back in university. Conventions are arbitrary but they're still important to implementation, so they should make sense and be consistent.

K final paragraph. To put it in more "human" terms imagine that what we call a "byte" is a grouping of 2 decimal digits instead of 8 binary digits (or 2 hex digits.) Then if we want to write the number 43083 in big-endian format which reverses byte order it would be 833004. That sucks. Big-endian sucks. Lilliput wins.

EDIT: Typo

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Apr 24, 2009 8:01 pm UTC
by Comic JK
The answer seems to be that we should make all our computers little-endian for the purpose of keeping low-order bits in low-numbered positions, change our network byte order too (that's easy enough), and finally, for full consistency, invert our ordinary decimal number system to make it little-endian as well.

Then when we're done, perhaps America can shift to the metric system.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Apr 24, 2009 9:28 pm UTC
by qbg
I understand the reasons for little-endian, but it is a little bit weird to see 0x12345678 in a hex editor as "78 56 34 12"...

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Apr 30, 2009 9:05 pm UTC
by MHD
I have tried to find out for some time now... Wha's the difference?

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Mar 21, 2014 6:06 pm UTC
by luke1985
If somebody will tell me that little endian is correct, I will tell him that he is certainly out of his mind.

There is no single reason to keep this stupid "endianness". Even the word "endianness" is a sign of stupidity - it's and idiotic word that probably was invented to keep some geeks out of thinking in terms of writing directions. Even with this, it's not what it can be compared, as writing from right to left makes some sense, but writing from right to left from down to up is just a sign of brain disorder.

Now the technical stuff:
Why for the f**k sake do I have to swap the bytes when using fread in C on a byte stream? This is inefficent in terms of performance, such a thing could be avoided without all this mess. Another thin are those endianness checks that also cost some CPU time.

And the philosophy behind "most signifcant byte has the highest address" is like saying that from now on you should read this post from bottom right to top left... oh wait no .. sorry. YOU SHOULD read it from top left to bottom right, but you should reverse each word.

And more to say: if you are going to say "no" to my post - consider yoursefl as a no-brainer and carry on.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sun Mar 23, 2014 11:33 pm UTC
by phlip
luke1985 wrote:Why for the f**k sake do I have to swap the bytes when using fread in C on a byte stream? This is inefficent in terms of performance, such a thing could be avoided without all this mess. Another thin are those endianness checks that also cost some CPU time.

That's only an argument for "everyone should do it the same", not "everyone should do it this way"... if the binary file and your memory architecture are both little-endian, you don't have to swap... neither if both are big-endian. You only have to swap if they're different.

I'll certainly agree that having either option be 100% standard would be far preferable to the current state of having both possibilities come up. But if I could have my choice of which one became that 100% standard, I'd pick little-endian all day.

luke1985 wrote:And the philosophy behind "most signifcant byte has the highest address" is like saying that from now on you should read this post from bottom right to top left... oh wait no .. sorry. YOU SHOULD read it from top left to bottom right, but you should reverse each word.

phlip wrote:The terms "left" and "right" make little sense when talking about the actual architecture... who knows how the registers are laid out on the chip? (Rhetorical question... of course there's some Intel/AMD engineers who know.)

Memory has no "left" or "right", "top" or "bottom". It just has lower addresses and higher addresses. Thinking about these in terms of a spacial arrangement might make things more convenient for our monkey brains, but that's solely an analogy that doesn't really apply to how things actually work. Laying memory out so that lower addresses are on the left, and then displaying it left-to-right top-to-bottom happens to be convenient when displaying text, as it lines up with how English-speakers read text, with character 0 on the left. On the other hand, laying a word out right-to-left would be more convenient when displaying numbers, as it would line up with how English-speakers read numbers, with digit 0 on the right. The fact that English has words and numbers laid out in opposite directions is no reason to do the same inside the computer...

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Mon Mar 24, 2014 12:07 am UTC
by Xenomortis
Little-endian because x86 is the only architecture I'm familiar with.
On the other hand, it's confusing when trying to read ASCII strings in hex dumps.

So I guess big-endian wins.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Mon Mar 24, 2014 1:11 pm UTC
by Flumble
qbg wrote:I understand the reasons for little-endian, but it is a little bit weird to see 0x12345678 in a hex editor as "78 56 34 12"...

Indeed. I'm in favour of big-endianness because it is consistent on bit and byte level.

I'd vote for a combination of LSb and LSB any day, as it makes for easy casting (GNU-GMP would love it), as mentioned by others, and it's consistent with streamed encodings like UTF. But good luck finding such a processor.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Mar 28, 2014 9:54 pm UTC
by Derek
Flumble wrote:Indeed. I'm in favour of big-endianness because it is consistent on bit and byte level.

I'd vote for a combination of LSb and LSB any day, as it makes for easy casting (GNU-GMP would love it), as mentioned by others, and it's consistent with streamed encodings like UTF. But good luck finding such a processor.

There is no such thing as bit-level endianness. Not on standard archietectures, anyways. The low bit is defined as the bit with the lowest value, and the high bit is the bit with the highest value. Nothing can be directly addressed below the byte level, so there is no possibility for different interpretations.

Little endian is obviously superior anyways. We wouldn't even have to have this discussions if some network interfaces weren't originally defined poorly.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Fri Mar 28, 2014 11:23 pm UTC
by moiraemachy
Defending little endian is just Stockholm Syndrome. I can only imagine that these people suffered pointlessly to adapt to an arbitrary convention and now are rationalizing. Writing or reading in big-endian just. makes. sense. Because silly conventions on how we write numbers normally? Yes, absolutely. Still, by far, the best reason possible.

Really people, stop being real-programmer tryhards. No one actually thinks intuitively of indexes. Want evidence of how shitty little endianness is? Even Intel couldn't steamroll it over the competition.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Wed Apr 02, 2014 1:26 pm UTC
by wumpus
moiraemachy wrote:Defending little endian is just Stockholm Syndrome. I can only imagine that these people suffered pointlessly to adapt to an arbitrary convention and now are rationalizing. Writing or reading in big-endian just. makes. sense. Because silly conventions on how we write numbers normally? Yes, absolutely. Still, by far, the best reason possible.

Really people, stop being real-programmer tryhards. No one actually thinks intuitively of indexes. Want evidence of how shitty little endianness is? Even Intel couldn't steamroll it over the competition.


Not quite. I suspect there is a large correlation between people who can/have read hexdumps and people who got their start with 8 bit computer and/or computers with an 8 bit wide databus. Little endian is more efficient in these cases and if you like the tiniest boxes, there you go.

In the end, if I was making an architecture (probably something that needs to be done to avoid a permanent x86 disaster), it would still be little endian just for compatibility's sake (ignoring the fact that phones are quickly outnumbering desktops).

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Apr 03, 2014 8:49 pm UTC
by hotaru
wumpus wrote:
moiraemachy wrote:In the end, if I was making an architecture (probably something that needs to be done to avoid a permanent x86 disaster), it would still be little endian just for compatibility's sake (ignoring the fact that phones are quickly outnumbering desktops).

it's interesting to note that most phones and tablets use ARM processors that can run as little endian or big endian, and they all use little endian.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Aug 27, 2015 10:05 am UTC
by stekp
Let's have big endian for everything. It makes sense to have the most significant thing first:

Numbers: ...hundreds -> tens -> units (we already do this!)

Dates: Let's have: year - month - date (as per ISO 8601)

Times: HH:MM:SS (we already do this!)

domain names: should really be: uk.co.bbc.www not www.bbc.co.uk

postal addresses: country -> city -> neighbourmood -> street -> house

Any other examples?

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Aug 27, 2015 12:19 pm UTC
by Flumble
stekp wrote:It makes sense to have the most significant thing first

For humans!
Computers aren't really into estimation and significant digits, they just want to do a complete calculation on numbers. So if the bus is narrow and you want to stream a calculation, it makes sense to start with the LSD (like you do an addition/multiplication from right to left, and you use LSD to calculate it faster).

Alright, it also makes sense to have the MSD first if the numbers represent a hierarchy/decision tree, like domain names. (it's also useful when you want detect a (multiplication) overflow early on)

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Aug 27, 2015 12:56 pm UTC
by Yakk
Even on computers, a low latency addition circuit will pre-calculate both possibilities for the MSD, then switch on that based on the carry-in from the previous block (or even further away).

The block that requires the most calculation in order to generate its value becomes the most significant one, so starting there marginally earlier makes sense (even if it is just shorter wires, and hence delay before the circuit stabilizes, to that block).

I haven't written a hardware multiplier in an age, but I presume a similar technique applies. You can calculate the least significant output from nothing but the least significant inputs, but calculating the most significant output depends on both entire inputs due to carry.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Aug 27, 2015 11:20 pm UTC
by Derek
It's probably worth mentioning btw that in languages that right from the right to the left, like Arabic and Hebrew, numbers are still written with the most significant digit on the left, and the least significant on the right. Food for thought.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Thu Aug 27, 2015 11:59 pm UTC
by commodorejohn
Goplat wrote:Little-endian is obviously superior. It is more logical, as the low bits exist at low addresses and the high bits at high addresses; the bit with a value of 2^n exists is part of the byte at base address +n/8, instead of +3-(n/8) or +7-(n/8) or whatever. It also allows for faster downward typecasting for indirect variables. If p is the address of a 32-bit value but you only want 16 bits, on a little-endian processor you can just use p as-is, while on a big-endian processor you have to add 2 first with the associated performance penalty.

All of this.

That said, I cannot deny my love for the Motorola 68k architecture.

Re: Let's get really esoteric: big-endian or little-endian?

Posted: Sat Mar 05, 2016 12:37 pm UTC
by Mikemk
Either are fine to me, but I don't like how Intel swaps halves