Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is big-endian dead?

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 193 posts

Ask HN: Is big-endian dead?

#1

Post by api »

Are there any big-endian chips still in production outside the embedded or specialty market?

Even MIPS and PPC now support a little-endian mode and are usually deployed that way. ARM is nearly always LE or deployed that way, and RISC-V is LE.

Edit: bonus factoid:

Little-endian is slightly more confusing for humans but may be objectively better for machines. On a little-endian machine integer size casts are free -- e.g. casting a uint64_t to uint32_t just means reading the first 4 bytes of it. On big-endian machines integer size casts require pointer math.

Re: Ask HN: Is big-endian dead?

#2

Post by tlb »

I used to use IETF's network order (big-endian) for everything on disk or over the wire, but I switched to little-endian around 2008. If I ever have to port to a big-endian machine I'll deal with it then. I haven't regretted it yet.

Re: Ask HN: Is big-endian dead?

#3

Post by api »

tlb wrote: post #2

I used to use IETF's network order (big-endian) for everything on disk or over the wire, but I switched to little-endian around 2008. If I ever have to port to a big-endian machine I'll deal with it then. I haven't regretted it yet.

Big-endian is the canonical form for storage and the wire because back when the Internet was designed most "pro" machines were big-endian: Sparc, old MIPS, old PPC, DEC Alpha, etc. All these are dead or dying now.

It's easy enough to deal with BE files and protocols by just swapping bytes. I'm referring to hardware architectures. Are there still any big-endian chips out there? Does it still make sense to support big-endian chips in new code as long as that code is never intended for embedded or very old systems?

Re: Ask HN: Is big-endian dead?

#4

Post by tlb »

api wrote: post #3
tlb wrote: post #2

I used to use IETF's network order (big-endian) for everything on disk or over the wire, but I switched to little-endian around 2008. If I ever have to port to a big-endian machine I'll deal with it then. I haven't regretted it yet.

Big-endian is the canonical form for storage and the wire because back when the Internet was designed most "pro" machines were big-endian: Sparc, old MIPS, old PPC, DEC Alpha, etc. All these are dead or dying now. It's easy enough to deal with BE files and protocols by just swapping bytes. I'm referring to hardware architectures. Are there still any big-endian chips out there? Does it still make sense to support big-…

Swapping bytes is a huge pain in the butt! When reading large binary files, it's so convenient and efficient to be able to mmap and make struct pointers right into the file. You can even deliver those files to web browsers and use JS's TypedArray to get random access into them.

(That requires a bit more than simply little-endian. It requires struct alignment and floating point formats to be the same. But with only a tiny bit of care it can be.)

For new code running in-core in 2018, I think little-endian is quite safe.

Re: Ask HN: Is big-endian dead?

#5

Post by api »

tlb wrote: post #4
api wrote: post #3

Earlier quoted context omitted.

Big-endian is the canonical form for storage and the wire because back when the Internet was designed most "pro" machines were big-endian: Sparc, old MIPS, old PPC, DEC Alpha, etc. All these are dead or dying now. It's easy enough to deal with BE files and protocols by just swapping bytes. I'm referring to hardware architectures. Are there still any big-endian chips out there? Does it still make sense to support big-…

Swapping bytes is a huge pain in the butt! When reading large binary files, it's so convenient and efficient to be able to mmap and make struct pointers right into the file. You can even deliver those files to web browsers and use JS's TypedArray to get random access into them. (That requires a bit more than simply little-endian. It requires struct alignment and floating point formats to be the same. But with only a…

Yes, and I think it follows that new protocols and new file formats should be little-endian if possible.

Re: Ask HN: Is big-endian dead?

#7

Post by ComputerGuru »

I’m presuming from your wording that you’re already aware, but for the benefit of others, ARM is bi-endian and can be used in either of LE or BE modes. However, most “in the field” configurations deploying real-world operating systems use it in LE mode as that makes porting everything so much easier.

Re: Ask HN: Is big-endian dead?

#8

Post by ajross »

Little endian is also better for multi-word addition/subtraction. Your first operand will be the low word, which your pointer conveniently already indexes. This was a classic trick in the days of 8 and 16 bit systems, and assembly code for modern modular crypto systems still uses it.

Really I think consensus is that the industry focus on big endian systems was actually a mistake. It prioritized programmer comfort in a regime where it never really mattered.

Re: Ask HN: Is big-endian dead?

#10

Post by faragon »

Little endian is genius. Not only because of size casts being "free" (because LE is compatible among "word" sizes -lower bits are at a known location-, while with BE you need to know the word size in order to locate the lower bits of the word), but also because of efficient bit I/O (using CPU registers as accumulators, and flushing with a word-size store), so variable size data can be encoded efficiently.
Post reply on HN