The Origin of the Terms Big-Endian and Little-Endian (2003)
1–10 of 24 posts
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#2Related: Note 127 https://www.rfc-editor.org/ien/ien137.txt
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#3I 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.
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#4I 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.
Network byte order.
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#5I 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.
Network byte order.
Which will also become a historical artifact as new protocols are made to use little endian.
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#6Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#7I 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.
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).
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#8Earlier quoted context omitted.
Which will also become a historical artifact as new protocols are made to use little endian.
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.
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#9I 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.
Network byte order.
Yeah people need to stop doing that going forward. It makes driver code a royal pain in the ass.
Re: The Origin of the Terms Big-Endian and Little-Endian (2003)
#10I 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 ```
On a little-endian machine you have to either do mental gymnastics to reorder the bytes, or set the item size to match your data item size.
``` 00000000 : 34 12 02 03 04 05 06 07 00000008 : 08 09 0A 0B 0C 0D 0E 0F ```
If we wrote the bytes with the LS byte on the right (just as we do for bits) then it wouldn't be an issue.
``` 00000000 : 07 06 05 04 03 02 12 34 00000008 : 0F 0E 0D 0C 0B 0A 09 08 ```