Hacker News Reader

Comment by tempodox | Hacker News Reader

I'm not much into low-level CPU architectures, so I have to ask: Is there a technical reason (performance or whatever) why LE would be objectively better than BE?

I do read hex dumps & disassemblies, and there LE is a huge pain in the backend. Everything is in reverse. Why would a sane programmer voluntarily use LE?

God Save the Network Byte Order!

View on HN

I think the main advantage I see in LE architectures is that integral types don't have to relocate. For example, the int32 value 30 is represented in memory as "1E 00 00 00". The int16 value 30 is represented in memory as "1E 00". So casting downwards means that the pointers are the same, and you just ignore the trailing 0s. Contrast this to BE architectures, where you have "00 00 00 1E" vs "00 1E" -- casting from the larger to the smaller type means that you have to move the pointer.

Yes, exactly. Maybe an example that's easier to visualize is when you learned to do arithmetic as a child. If I gave you a bunch of numbers to add like 57, 9, and 318 the first thing you would do is right justify them all. For any math operation, you start at the least significant digit and work up. This is ultimately equivalent to the int32/int16 example you gave -- if you are trying to operate on numbers of different length you have to first ensure that their LSBs line up. Little-endian is like writing your decimal integers right-justified on the blackboard.

So little-endian is (slightly) more convenient for machines and big-endian is (slightly) more convenient to humans reading memory dumps.

The unfortunate thing is that "network byte order" is big-endian so it's still the traditional endianness to use for wire protocols or on-disk formats. In my own designs I've switched to specifying fixed-width integers as little-endian which makes more sense for 99.9% of computers today.

Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x.

Contrast with a big-endian representation, where the byte at offset x would have weight 256^(length - 1 - x).

Except that it's often convenient for encodings to sort lexographically and numerically the same way. There are several multi-precision number formats with this property, but they're all either equally slow to load on any endian machine, or faster to load on big-endian machines.

Also, on a 64-bit big-endian architecture, you don't need specialized string comparison instructions to get efficient string comparisons. The code is only slightly more complicated on BE architectures that only support aligned 64-bit loads.

>Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x.

This is literally the opposite of how most programmers in the world write numbers naturally.

See "1234". The digit at offset x from the right has weight 10^x. That corresponds to big-endian.

Considering that the only important difference between little and big endian is when people have to read or write it by hand, we should probably model it after common human representation...

By the way, this "natural" way of writing numbers comes unchanged from right-to-left writing system of Arabic. They naturally read 1234 starting from the lowest significant digit (here, '4').

Think about the irony :)

I'm not sure about Arabic, but my understanding of Hebrew (another member of the Semitic language family) is that they still pronounce the numbers left to right, and if a line break forces digits to be split across lines, the most significant digits are put on the top line.

You got me curious. I googled and found[1] that indeed they only pronounce numbers 21-99 that way, e.g. for 31 the order of words is "one thirty", but higher order components go left to right, e.g. for 25031 the order of words is "five twenty thousand one thirty".

1. http://arabic.tripod.com/VocabNumbers.htm

Modern processors can perform this cast in a negligible amount of time, and due to modern memory architecture there's no advantage to reading 2 bytes instead of 4.

Little-endian has a major advantage over big-endian...on eight-bit architectures: as you expand the size of the number, you can keep using up new digits at the end of the range, rather than the beginning. This means that you can more easily expand field widths.

Beyond that, it's called after two stupid factions in Gulliver's Travels for a reason...

Though. it's sometimes convenient to have a lexographical sort result in a numeric ordering. For instance, if you're storing timestamps as multi-precision integers using a Rice-Golomb encoding that sorts the same way lexographically and numerically, decoding is faster if your CPU is big-endian.

Little-endian is generally better for compilers, to the extent that it matters. For example, with SIMD, it makes most sense to number the lanes in the same direction as addresses in memory, so that lane 0 is at offset 0 when doing a load or store. And if you want to reinterpret the bits of a SIMD value as a different type, little-endian is the only sane way to do it. And so on.

I've become fond of thinking about little-endian becoming known as a universal "CPU byte order", to complement "network byte order". Each order makes the most sense for its domain.

I won't give you a technical reason, but rather respond to the second part about LE and sanity.

Actually LE is the natural order and the question is why anybody sane would prefer BE. The reason you think otherwise is because you view hexdumps the wrong way.

A hexdump shows hexadecimal bytes. Isolate one byte and number the bits -- 76543210, right to left. Number the nibbles -- 10, right to left. Now number the bytes -- 0123..., left to right?

Display your hexdumps with addresses increasing right to left and LE makes perfect sense. This is how numbers are written, so the convention should be followed when displaying numbers.

Why on earth would anyone number the bytes right to left? Do you want strings to appear backward as well? But only the portion of a string on one line, the fragments will still be in correct order. Or do you advocate numbering from bottom to top too?

I am talking about the view of the hex data. That view is about showing numbers, and the common complaint about LE is that numbers are reversed, but this is only the case when you break the convention of displaying numbers right to left.

For showing strings it's better to use left to right, as that's the convention for text.

most hex editors will show you the ascii value for hex that falls within the range of ascii, which can be useful to humans.

No, it's just that Intel won, mostly because of IBM choosing it.

Big-endian has always made more sense to me, since digits are laid out in memory the same way they are laid out in writing and therefore in my brain. Little-endian just seems like a cheap '70s kludge that accidentally became dominant thanks to Intel.

Money.

When Motorola 68000 was out, it was doing 32bits linear addressing.

The mov operation would load directly from the memory by using a direct addressing.

Wiring 32 wires is expensive.

Wiring 2 overlaping address bus of 16 bits partially ovelapping was less. Intel CPU ASM works big endian because we all prefer to write AND 0xFF, DSI to get the 8 lower bit of a number.

The first register would hit segment, and the second the offset.

Hence you would first need to load the page (that would wire the multiplexing) to get the offset in the page/segment.

The addressing bus would be accessed with a stack. So first you push the lower 16 bits, and then the highest 16 bits. Which would revert since its a FIFO in first loading the segment address, then the offset address. The cost of this "savings" in terms of CPU cycle was marginal while the gain in money was tremenduous.

Reply on news.ycombinator.com