Hacker News Reader

Comment by atq2119 | Hacker News Reader

Little endian has nothing to do with CISC vs RISC or x86 though. Everybody is little endian today.

x86 helped with that historically, certainly, but fundamentally endianness just doesn't matter most of the time, and when it does, little endian makes more sense from first principles.

View on HN

I think big endian is better: with little endian, treating a pointer to one size integer as a pointer to a different size integer has a decent chance of working, which allows bugs and sloppiness to fester. With big endian, screwing up your pointer type is very unlikely to work, which is IMO a good thing.

> Everybody is little endian today.

ACKCHYUALLY, PowerPC (POWER9 included) supports both big and little endian. Software wise, last I checked the Linux kernel, Debian (PPC port), Gentoo, FreeBSD, and several other major projects supported both. I believe KVM also supports flipping VM endianness versus the hypervisor.

Acknowledged, of course, that the spirit of what you said is indeed correct - the majority of systems in active use are little endian.

ARM too.

https://developer.arm.com/tools-and-software/open-source-sof...

See: > AArch64 GNU/Linux big-endian target (aarch64_be-linux-gnu)

>and when it does, little endian makes more sense from first principles

Could you explain why little endian would make more sense? While I dont take side in this debate, I have always thought Big Endian would make more sense from First principles.

There are two main applications where I find little endian is more logical: big integer implementations, and bit stream encoding.

With big integers, the logic is simple: if you use little endian, you can operate on the same memory representation of the bigints quite easily with machine integers of different sizes.

A similar phenomenon happens with bit encoding. Let's say you want to encode a sequence of 25-bit integers tightly packed in memory. How do you do that? With little endian, you get a somewhat more natural representation especially for seeking into the bitstream (especially for architectures that allow unaligned memory accesses).

> With big integers, the logic is simple: if you use little endian, you can operate on the same memory representation of the bigints quite easily with machine integers of different sizes.

That's true with big endian too, but you just have to store your integers in the opposite way as you would on little endian: with the MSB at the lowest address (which of course is the same as the distinction between little and big endian in the first place).

Basically the bigint layout has to be compatible with the the endianess.

I don't know what bignum implementations do in practice on big endian systems though.

If anyone wants to see why little endian is better try implementing a sigint. Big endian makes everything backwards in terms of iteration order.

You are presenting argument in favor of little endian, yet you're provide enough information that is only useful for someone who already knows the answer.

The answer is also only useful to those who know it? I mean, nerds love to shout about the superiority of this or that, but they're mostly just parroting their tribe motto. If you have reason to really care about endian order, I would encourage you to do more research than you'll find in an HN comment. Perhaps there's even more than one right answer depending on circumstance.

I don't have too much knowledge in that area, but my understanding is as follows: for a software engineer big endian simpler to use, for hardware engineer little endian is simpler to implement.

I think it's similar to scientific calculator vs RPN calculator.

I don't think big vs little endian makes a difference in terms of hardware implementation. It's just a simple swap of wires.

it's more optimal when you're doing pipelining, for example adding two numbers to do the operation you start from the lowest byte and add them together and move up. With little endian bytes are already positioned in the order you want.

x86 architecture also was big on backward compatibility. You have registers that can be accessed as 8bit, 16bit, 32bit (and I believe 64bit) adding the extra bytes after similarly makes it easier, because the little significant bits are always in the same place.

Again, I don't have extensive understanding of hardware side, so I might be wrong.

I know endianness is separate from CISC vs RISC, and mostly a pointless and useless debate.

Except MIPS and the network.

MIPS processors have mostly been replaced by ARM already.

Not in routers.

I work in that area. All consumer-grade router/gateway SoCs from Broadcom have been exclusively ARM for several years now. They were MIPS before.

Caviun also went ARM, and is now owned by Marvell.

Reply on news.ycombinator.com