8 ms·
Byte Ordering: On Holy Wars and a Plea for Peace (1980)
- feverzsj 2y agoI think most industry wire protocols are still big endian.
- unnah 2y agoYes, the so-called "network byte order". Now that big-endian has lost on all other fronts, it is time to switch to little-endian in all future network protocols. We could call it the krowten byte order.
- kstenerud 2y agoI actually did a writeup on this: https://www.technicalsourcery.net/posts/on-endianness/ https://www.technicalsourcery.net/posts/on-endianness/ TLDR: Little endian is better for most data situations (and incidentally is a more natural ordering for humans), so it's good that it won out in the end.
- deleted 2y ago[deleted]
- Tor3 2y agoWell, the bits jump around.. bytes are ordered, but the bits aren't, with LE (between bytes) so there's always room for a never-ending discussion about what's best ("Are you a bit person? Or a byte person? Then your preferences may differ"). The best argument for LE would be that a processor like e.g. the 6502 could start processing the least significant byte while fetching the most significant byte, and that on a VAX you could pass a 4-byte integer to a Fortran function expecting a 2-byte integer and it would actually work (as long as the value was > 65536). That was actually done a lot back in the day.. and created problems when recompiling the Fortran code for a BE architecture.
- deleted 2y ago[deleted]
- akira2501 2y agoLE is easier to handle, BE is easier to read.
- nicce 2y agoLE is also much faster in terms of performance. For example, because of the efficiency of the add or subtract operations.
- bregma 2y agoAt the circuit level (where the performance is determined) it doesn't matter if your half-adder combines its left and right inputs or its right and left inputs. So no, there is no difference in efficiency or performance when it comes to endianness. The only time it would make a difference is if your memory bus width is less than your wordsize and you lack any kind of caching.
- foldr 2y agoI wonder if you're thinking of the efficiency penalty for dealing with big-endian values on a little-endian architecture. As the sister comment says, there's nothing inherently more efficient about either byte order when it comes to the processor performing arithmetic operations in on values in its native byte order.
- p_l 2y agoUnless you have a bit-serial machine (close to extinct), LE vs BE matters not for ALU so long as you don't have to run the computation through multiple rounds (like having 32bit ALU but doing 64bit arithmetic)
- Tor3 2y ago.. or a 6502 microprocessor doing 16-bit arithmetic with an 8-bit ALU. The 6502 was designed by a team who used to work with the big endian 6800, and chose little endian for their 6502 for a slight performance improvement.
- weinzierl 2y agoBrilliant write up! I do not really understand the "Sorting unknown uint-struct blobs" point. Could you give an example or explain in more detail, what a "unknown uint-struct blob" is? The odd/even advantage could be put even stronger, because every additional bit you know from the little end gives additional information about the number's divisibility. For example, one bit tells divisibility by two (aka ofd/even), two bits tell divisibility by four, and so on.
- kstenerud 2y agoFor example, if you had a file that comprised the following struct: struct someblob { uint64_t timestamp; uint64_t checksum; uint32_t item_count; struct something items[0]; }; Even if you didn't know that a collection of files were structured this way, you could still read, say, the first 128 bits as an unsigned integer and compare them, and they'd just happen to be naturally ordered because the timestamp field grows from right to left, and would have precedence over the "lower 64 bits" of the checksum field. It's a very minor benefit (of dubious real-world utility), but I wanted to be comprehensive :P
- tekacs 2y agoThis comes in really really handy in lexicographical ordering. For example, if storing in the keys of a KV store a pattern of: [u32, String, u32, String, …] If you want those arrays to be sorted lexicographically, you’ll want to store those u32 instances in big endian, so that both those and the strings sort from left-to-right.
- weinzierl 2y agoThanks! That makes sense. Mentally, I would put this in the "conventional" advantage category, because it relies on comparing fixed length chunks of memory and computationally it should not make a difference if `timestamp` is stored LE or BE for sorting.
- kstenerud 2y agoActually, in this case it would. Consider the layout (byte-by-byte): BE: t8 t7 t6 t5 t4 t3 t2 t1 c8 c7 c6 c5 c4 c3 c2 c1 In the big endian case, the byte-by-byte of the struct naturally places the timestamp at the high end of the 128 bit value you blindly read. LE: t1 t2 t3 t4 t5 t6 t7 t8 c1 c2 c3 c4 c5 c6 c7 c8 In the little endian case, it's the CHECKSUM at the high end of the 128 bit value.
- wakawaka28 2y agoThe writeup does not convey a consistent message on "naturalness"... The normal way numbers are written in most or all of the world is big-endian so obviously that is the one that would be found "natural" to most people, regardless of whatever perceived advantages going little-endian has. Furthermore, number names in every language I know of start with the biggest units. The direction of writing does not matter so much as the direction of reading. Anything other than big-endian would require readers to skip around in text to actually say the name of a number in a sentence.
- kstenerud 2y agoWhat we consider "natural" now is not what was originally considered "natural" during the early centuries of the Hindu-Arabic numerals' journey. In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Even Greek numbers underwent reversals in the early years (earliest known evidence circa 4th century BC).
- Someone 2y ago> In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Also in English, with the numbers thirteen through nineteen (and, fairly well hidden, eleven and twelve)
- somat 2y agoI always thought eleven and twelve were remnants from when the system was more base twelveish. It was never actually base 12, that would have required inventing 0, But sometimes I wonder if we would not have been better off sticking with base 12. And before someone chimes in with "base 10 is natural because we have 10 fingers" no we have 8 fingers, by that logic we should be using base 8, but the real winner in using base 12 is count using your finger bones(there are twelve of them) and use your thumb to keep your count, use both hands and you can get to 100(144 in base 10). this is probably why base twelveish was so common, shepards counting sheep. try counting to 100 in base 10 on your fingers, not so natural now is it.
- ale42 2y agoHave a look at the date of the document... although the content is serious, the way it's discussed might be a bit in the line of these: https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C...
- pianosaurus 2y agoWho needs CSS for justified text when you can just do it 1980-style monospaced justification? This makes me happy, and I have no idea why.
- hoseja 2y agoI hate it so much, full of wrong linebreaks. I don't need typewriter or dot matrix compatibility.
- evnix 2y agoRead it from a tiny screen, you will realise why it is a bad idea.
- 082349872349872 2y agoReading from a tiny screen being the root bad idea.
- nine_k 2y agoI remember using physical screens that only had 64 or even 40 columns. (A printout was more practical for reading anyway. Just tolerate a few minutes of dot-matrix noise.)
- kps 2y agoIt wasn't meant to be read from a screen. (A browser doesn't show the Form Feed character at each page number.)
- fuglede_ 2y agoThis tom7 video might also make you happy then: https://www.youtube.com/watch?v=Y65FRxE7uMc https://www.youtube.com/watch?v=Y65FRxE7uMc
- petee 2y agoProbably because it just works, simply. Whereas with the complexity we have today we can barely align things consistently; it's almost comedy Tip for those with mobile issues: rotate to landscape and the words get bigger ;)
- SSLy 2y agoLmao, this has raw actual-ANSI-control-code 000C <control> = FORM FEED (FF) in the text.
- dasyatidprime 2y ago^L is still normal as a separator in Emacs Lisp code files!
- p_l 2y agoTECO (and thus Emacs) supported a commands like "read page" which turned into movement by page in Emacs, which is why ^L shows up in Emacs Lisp (and sometimes similar vintage code)
- ginko 2y agoTo this day I think that article mixed up the terms, causing confusion ever since. "Little-endian" to me implies that the least significant byte of a word is at the end of a byte sequence, but it's the other way round. I understand that it's from Gulliver's Travels where it's about which end to start breaking an egg from - but without knowing this you can easily end up getting this wrong.
- ithkuil 2y agoNatural languages... The word "End" can also mean any "extremity" and not just the opposite of "beginning". Otherwise phrases "on both ends of the spectrum" wouldn't make sense. Thus, a positional encoding of a number has one side (end) where the impact of digits is much higher (big) than the other side (end) where the impact is lower (little). Little end: the side with lower "weight" Big end: the side with higher "weight" Being "little endian" is a property of the encoding or architecture, not the property of the word. The word is not "little endian", i.e. its "end" is not "little". The encoding is little endian in that it starts with the little end of the word. You're rightly confused because the fact we're now suddenly talking about the start of the word is implicit and based on the assumption that the reader knows Gulliver's tale.
- imtringued 2y agoYou're doubling down on the ambiguity and thereby proving the point. If end means start, then why use this word? Little endian is in reality little startian and big endian is big startian. In fact, we could simplify this even further and just call big endian, startian and little endian, just endian.
- ithkuil 2y agoYou're right it's ambiguous. It's a playful reference to a piece of literature. It's also quite an old terminology which is not going to change. If we could come up with a new terminology from the start we could find better options. For example: * Least/Most Significant First (LSF / MSF) * Low/High Address Least Significant (LALS/HALS) Etc
- 082349872349872 2y ago> Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. —SKB
- yarg 2y agoThat reads like an XKCD alt-text. (That would've been RM; SKB is Stan Kelly-Bootle)
- bonoboTP 2y agoIt's actually somewhat of a reality in some image processing code, and some people feel really passionate about whether the topleft corner pixel is located at (0.5,0.5) or (0,0).
- yarg 2y agoFunnily enough, I actually wrote code that does that very thing this morning.
- djbusby 2y agoThe center of the pixel is at 0.5 but the top left of the pixel at the top left is 0. And the bottom right of the top left pixel is at 1.
- marcosdumay 2y agoOr the top left is located at -0.5 and every other place has the coordinates one would naively expect.
- 1000100_1000101 2y agoDirect3D made this a thing. Trying to draw unscaled 2D elements you often end up with blurry images as it bilinearly filters with the neighbouring pixels. This is because of a mess with where it considered pixels located, where texture samples are considered located, and where, when rasterizing an included pixel, the texture coordinates sampled. See detail at [0]. If your graphics API was blurring all your images, you'd be passionate about that half-pixel offset too. [0] https://www.gamedev.net/blogs/entry/1848486-understanding-half-pixel-and-half-texel-offsets/ https://www.gamedev.net/blogs/entry/1848486-understanding-ha...
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- USiBqidmOOkAqRb 2y agoSilly aside: I didn't read the book and was very confused for a long time since I assumed endian meant the specified byte goes last.
- djbusby 2y agoLittle End In (first) == little endian.
- dcminter 2y agoIt may be a handy mnemonic, but it's not the etymology (you may know this, but I can't resist the pedantic opportunity!) It comes from Swift's satire about egg eaters. The end in question was the small or large end of the egg and Big Endians broke the big end with the spoon - i.e. it went into the egg cup small end down. The -ian suffix here is analogous to Christ-ian or Keynes-ian and has nothing to do with "in".
- tempodox 2y agoWhile I prefer to crack my eggs from the little end, I insist on big-endian byte order. Sadly, modern CPUs are mostly made by barbarians (i.e. Little-Endians).