Comments on: Representing Data - Notes on Big And Little Endian Encodings http://ztkfg.com/2020/07/sorting-out-big-and-little-endian/ 198.211.113.164 // 6326 273B 61A7 00AF 4CD9 5A7B 8C6C AB19 24A6 4DEC Sat, 04 Apr 2026 10:15:35 +0000 http://polimedia.us hourly 1 By: Adlai Chandrasekhar http://ztkfg.com/2020/07/sorting-out-big-and-little-endian/#comment-350 Adlai Chandrasekhar Tue, 20 Oct 2020 14:30:34 +0000 http://ztkfg.com/?p=476#comment-350 At the risk of further extending the tangential nitpicks: Bits within flag registers are typically modified one at a time, by whichever operation has caused that bit to have its value set. At the risk of further extending the tangential nitpicks:

Bits within flag registers are typically modified one at a time, by whichever operation has caused that bit to have its value set.

]]> By: whaack http://ztkfg.com/2020/07/sorting-out-big-and-little-endian/#comment-334 whaack Thu, 23 Jul 2020 19:13:47 +0000 http://ztkfg.com/?p=476#comment-334 Yes, my incorrect assumption was that although the machine could only access bits one-word-at-a-time, those bits did have some notion of an address. And I also believed that perhaps some machines were this 'mixed order monster.' From doing a bit more noobsearch I understand now that it's only the <i>bytes</i> that have addresses. (Argueably a machine could be designed to only give addresses to words.) Yes, my incorrect assumption was that although the machine could only access bits one-word-at-a-time, those bits did have some notion of an address. And I also believed that perhaps some machines were this 'mixed order monster.'

From doing a bit more noobsearch I understand now that it's only the bytes that have addresses. (Argueably a machine could be designed to only give addresses to words.)

]]> By: Jacob Welsh http://ztkfg.com/2020/07/sorting-out-big-and-little-endian/#comment-333 Jacob Welsh Thu, 23 Jul 2020 17:12:03 +0000 http://ztkfg.com/?p=476#comment-333 It's not that I'm quibbling over an omitted detail though; it's right in the quoted sentence: an assumption that bits have addresses. Certainly you could have a machine where they do, but if it worked as you described, it would be a mixed-order monster rather than LE. The reason people tend to think LE is somehow intrinsically "reversed" is our human convention of writing numbers BE. Incidentally there'd be some advantages if we'd gone the other way: we wouldn't have to right-align numeric fields in tables for the place values to line up, and addition/subtraction/multiplication would proceed left-to-right the same as writing. It's not that I'm quibbling over an omitted detail though; it's right in the quoted sentence: an assumption that bits have addresses. Certainly you could have a machine where they do, but if it worked as you described, it would be a mixed-order monster rather than LE.

The reason people tend to think LE is somehow intrinsically "reversed" is our human convention of writing numbers BE. Incidentally there'd be some advantages if we'd gone the other way: we wouldn't have to right-align numeric fields in tables for the place values to line up, and addition/subtraction/multiplication would proceed left-to-right the same as writing.

]]> By: whaack http://ztkfg.com/2020/07/sorting-out-big-and-little-endian/#comment-331 whaack Thu, 23 Jul 2020 14:36:12 +0000 http://ztkfg.com/?p=476#comment-331 I see. I knew that bits are not individually accessible, but thought it was okay to omit that detail from my overview. So the LE machine may or may not have the internal bits of a byte reversed. But regardless of how the bits are layed out physically the external representation for a single byte is always displayed in big endian. With this understanding, I gather that how the bits are laid out on a per byte or per word level is black-box'd. I see. I knew that bits are not individually accessible, but thought it was okay to omit that detail from my overview.

So the LE machine may or may not have the internal bits of a byte reversed. But regardless of how the bits are layed out physically the external representation for a single byte is always displayed in big endian. With this understanding, I gather that how the bits are laid out on a per byte or per word level is black-box'd.

]]> By: Jacob Welsh http://ztkfg.com/2020/07/sorting-out-big-and-little-endian/#comment-330 Jacob Welsh Sun, 19 Jul 2020 21:41:18 +0000 http://ztkfg.com/?p=476#comment-330 > However, within that byte, the bit with the lowest address is the most significant. That's not quite it. What you seem to miss is that bits are not individually addressable in typical CPU instruction sets: you move data between registers and memory a word at a time or at the smallest a byte at a time. You can get at individual bits through shift/mask operations but those are defined arithmetically i.e. "shift right" always means shifting toward the least significant end, independent of how the bits are laid out physically. The annoying appearance of mixed ordering comes into play with external representations with sub-byte-level symbols, such as a hex dump. With hex, it's a well entrenched convention to write the two half-byte digits ('nibbles") big-endian. Thus if you take a numeric 0x12345678, read it byte-at-a-time on an LE machine, and display each byte using the normal programming language hex facility, you get "78 56 34 12" rather than the 87654321 that the CPU and RAM could well be using internally. In TRB, from what I've seen so far the extra byte reversal is done only for parsing/display of hashes, i.e. block and tx IDs and not numeric fields. <a href="http://fixpoint.welshcomputing.com/2020/preliminary-report-on-the-bitcoind-hex-conversion-mess/" rel="nofollow">See also</a>. > However, within that byte, the bit with the lowest address is the most significant.

That's not quite it. What you seem to miss is that bits are not individually addressable in typical CPU instruction sets: you move data between registers and memory a word at a time or at the smallest a byte at a time. You can get at individual bits through shift/mask operations but those are defined arithmetically i.e. "shift right" always means shifting toward the least significant end, independent of how the bits are laid out physically.

The annoying appearance of mixed ordering comes into play with external representations with sub-byte-level symbols, such as a hex dump. With hex, it's a well entrenched convention to write the two half-byte digits ('nibbles") big-endian. Thus if you take a numeric 0x12345678, read it byte-at-a-time on an LE machine, and display each byte using the normal programming language hex facility, you get "78 56 34 12" rather than the 87654321 that the CPU and RAM could well be using internally.

In TRB, from what I've seen so far the extra byte reversal is done only for parsing/display of hashes, i.e. block and tx IDs and not numeric fields. See also.

]]>