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

The Origin of the Terms Big-Endian and Little-Endian (2003)

ling.upenn.edu

Post reply on HN
Print view View original

11–20 of 24 posts

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#11

Post by rep_lodsb »

weebull wrote: post #10
RcouF1uZ4gsC wrote: post #3

I think there is peace now because little-endian won. All modern CPU are little endian (or dual selectable) Other than backward compatibility, there is non need for little endian.

There's one area I wish we did differently which I think is a hang-over from big-endian. It's the order of bytes when we write out hex dumps of memory. You'll always get something like this: ``` 00000000 : 00 01 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ``` On a big-endian machine, when you wrote 0x1234 to address 0x0000000 you got: ``` 00000000 : 12 34 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F…

!tfel-ot-thgir eb dluow ,redro dleif sa llew sa ,sgnirts lla neht tuB

It could be argued that little endian is the more natural way to write numbers anyway, for both humans and computers. The positional numbering system came to the West via Arabic, after all.

Most of the confusion when reading hex dumps seems to arise from how the two nibbles of each byte being in the familiar left-to-right order clashes with the order of bytes in a larger number. Swap the nibbles, and you get "43 21", which would be almost as easy to read as "12 34".

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#12

Post by jmclnx »

IIRC, Mark Williams Company had a patent on the ability to run the same binary on both big and little endian machines.

https://patents.justia.com/assignee/mark-williams-company

https://en.wikipedia.org/wiki/Mark_Williams_Company

I wonder what happened to it and why could Linux not use it. I think it was released under a free licence.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#13

Post by rep_lodsb »

flohofwoe wrote: post #7
mwkaufma wrote: post #4

Earlier quoted context omitted.

Network byte order.

Modern-ish CPUs have instructions to load big-endian data without having to switch into a special 'big-endian mode', and compilers can optimize into those instructions so language don't need to add special intrinsics: https://www.godbolt.org/z/q3hMPq78v ...but even without specialized instructions the transformation should be pretty much free on pipelined CPUs (compared to a memory load anyway).

It's still one more thing you need to keep in mind when writing code, at least in languages that don't have a separate data type for different-endian fields.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#14

Post by rep_lodsb »

jmclnx wrote: post #12

IIRC, Mark Williams Company had a patent on the ability to run the same binary on both big and little endian machines. https://patents.justia.com/assignee/mark-williams-company https://en.wikipedia.org/wiki/Mark_Williams_Company I wonder what happened to it and why could Linux not use it. I think it was released under a free licence.

That just describes using conversion routines for data, after loading and before storing to some standardized on-disk / network format.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#15

Post by nineteen999 »

dontlaugh wrote: post #8
nineteen999 wrote: post #6

Earlier quoted context omitted.

For which protocols? TCP/IP itself is network byte order all the way down to the bottom of the jar.

For example, Cap'n Proto and QUIC are both little endian. TCP is becoming increasingly less relevant, although I don't know if it'll ever actually disappear.

Capn Proto and QUIC are are layer 6 and 7 (presentation and application protocols respectively). Quic is built on top of UDP.

Layers 3-4 (network, transport) are both big-endian - IP packet headers and TCP/UDP headers use big-endian format.

This means you can't have an IP stack (let alone TCP/UDP, Quic, Capn Proto) that's little-endian all the way through without breaking the internet.

Outside the webdev bubble, it's pretty much QUIC that is irrelevant - it's just another UDP based application protocol.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#16

Post by dontlaugh »

nineteen999 wrote: post #15
dontlaugh wrote: post #8

Earlier quoted context omitted.

For example, Cap'n Proto and QUIC are both little endian. TCP is becoming increasingly less relevant, although I don't know if it'll ever actually disappear.

Capn Proto and QUIC are are layer 6 and 7 (presentation and application protocols respectively). Quic is built on top of UDP. Layers 3-4 (network, transport) are both big-endian - IP packet headers and TCP/UDP headers use big-endian format. This means you can't have an IP stack (let alone TCP/UDP, Quic, Capn Proto) that's little-endian all the way through without breaking the internet. Outside the webdev bubble, it's…

UDP is an implementation detail of QUIC, just a way to give IP-ish functionality to userspace. In practice, QUIC is a TCP alternative.

The OSI layer model is not necessarily as relevant as it used to be.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#17

Post by Veserv »

dontlaugh wrote: post #8
nineteen999 wrote: post #6

Earlier quoted context omitted.

For which protocols? TCP/IP itself is network byte order all the way down to the bottom of the jar.

For example, Cap'n Proto and QUIC are both little endian. TCP is becoming increasingly less relevant, although I don't know if it'll ever actually disappear.

Foolishly, QUIC is not little-endian [1]. The headers are defined to be big-endian. Though, obviously, none of UDP, TCP, or QUIC define the endianness of their payload so you can at least kill it at that layer.

[1] https://www.rfc-editor.org/rfc/rfc9000.html#name-notational-...

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#18

Post by dontlaugh »

Veserv wrote: post #17
dontlaugh wrote: post #8

Earlier quoted context omitted.

For example, Cap'n Proto and QUIC are both little endian. TCP is becoming increasingly less relevant, although I don't know if it'll ever actually disappear.

Foolishly, QUIC is not little-endian [1]. The headers are defined to be big-endian. Though, obviously, none of UDP, TCP, or QUIC define the endianness of their payload so you can at least kill it at that layer. [1] https://www.rfc-editor.org/rfc/rfc9000.html#name-notational-...

Oh really? I must’ve misread.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#19

Post by nineteen999 »

dontlaugh wrote: post #16
nineteen999 wrote: post #15

Earlier quoted context omitted.

Capn Proto and QUIC are are layer 6 and 7 (presentation and application protocols respectively). Quic is built on top of UDP. Layers 3-4 (network, transport) are both big-endian - IP packet headers and TCP/UDP headers use big-endian format. This means you can't have an IP stack (let alone TCP/UDP, Quic, Capn Proto) that's little-endian all the way through without breaking the internet. Outside the webdev bubble, it's…

UDP is an implementation detail of QUIC, just a way to give IP-ish functionality to userspace. In practice, QUIC is a TCP alternative. The OSI layer model is not necessarily as relevant as it used to be.

You're kind of saying "look over here!" but I'm not that easily distracted. You said "Which will also become a historical artifact as new protocols are made to use little endian". It's never going to become a historical artifact in our lifetimes. As the peer poster pointed out, QUIC itself has big-endian header fields. IPv4/IPv6 both use big-endian at layer 3.

The OSI layer model is extremely relevant to the Cisco network engineers running the edges of the large FAANG companies, hyperscalers etc. that connect them to the internet.

Re: The Origin of the Terms Big-Endian and Little-Endian (2003)

#20

Post by Gibbon1 »

rep_lodsb wrote: post #11
weebull wrote: post #10

Earlier quoted context omitted.

There's one area I wish we did differently which I think is a hang-over from big-endian. It's the order of bytes when we write out hex dumps of memory. You'll always get something like this: ``` 00000000 : 00 01 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ``` On a big-endian machine, when you wrote 0x1234 to address 0x0000000 you got: ``` 00000000 : 12 34 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F…

!tfel-ot-thgir eb dluow ,redro dleif sa llew sa ,sgnirts lla neht tuB It could be argued that little endian is the more natural way to write numbers anyway, for both humans and computers. The positional numbering system came to the West via Arabic, after all. Most of the confusion when reading hex dumps seems to arise from how the two nibbles of each byte being in the familiar left-to-right order clashes with the ord…

For me I think the issue is the way you think of memory.

You can think of memory are a store of register sized values. Big endian sort of make some sense when you think of it that way.

Or you can think of it as arbitrarily sized data. It's arbitrary data then big endian is just a pain the ass. And code written to handle both big and little endian is obnoxious.

Post reply on HN