[HN Gopher] Ask HN: Why is the byte order little-endian, but the...
___________________________________________________________________
Ask HN: Why is the byte order little-endian, but the bit order is
big-endian?
For context: on the linux rust support thread there was a
discussion about little-endian vs big endian. But nobody seemed to
say anything about the bit-order.
https://news.ycombinator.com/item?id=27746851
Author : bruce343434
Score : 16 points
Date : 2021-07-06 15:51 UTC (7 hours ago)
| nemetroid wrote:
| I think you need to qualify in what sense bits are big endian.
| "Bit 0" is reasonably the first one, and that usually refers to
| the least significant bit.
| bruce343434 wrote:
| Yes. In the same way that "byte 0" is the last byte in little
| endian, "bit 0" is the first bit in big endian.
| nemetroid wrote:
| > "byte 0" is the last byte in little endian
|
| What do you mean by "last byte" here? On a little endian
| machine, a two-byte integer stored at address x has its less
| significant byte at x+0, and its more significant byte at
| x+1.
|
| Going by those numbers, byte 0 is the least significant byte,
| much like bit 0 is the least significant bit.
| kats wrote:
| https://stackoverflow.com/a/36263273
| JoeAltmaier wrote:
| On a computer bus, bits are often transmitted in parallel. So
| there is no order; they all arrive at the same time. On Ethernet
| bits are transmitted one at a time, and are 'little-endian'.
| kabdib wrote:
| IBM's 360 series numbers bits from 0 to 31, with bit 0 being most
| significant.
|
| I _know_ I 've seen material where a CPU numbered bits from 1 to
| 32, with 1 being most significant, but I can't remember the
| manufacturer.
|
| Let us not forget the PDP-11, whose 32-bit format is both BE (in
| bytes) and LE (in words).
| mytailorisrich wrote:
| In term of hardware I think this is irrelevant: lines are
| labelled 0 to _n_ , that's unequivocal.
|
| Now, why is bit 0 the lowest? Well I think this follows naturally
| from binary representation as a polynomial of powers or two. So
| bit 0 is 2^0, bit 1 is 2^1, etc. Representation with digits in
| base 2 also simply follows standard order of numerals: 100 is one
| hundred, not zero zero one whether in decimal or binary.
|
| The issue of big-endian vs little-endian really arises when you
| want to represent a word across bytes. Different people made
| different choices, since they are equally valid.
|
| Now, over a serial line you can also decide to transmit bits one
| way or the other, and this can indeed go either way depending on
| the interface, either LSB (least significant bit) first or MSB
| (most significant bit) first.
| bruce343434 wrote:
| I suppose so. But in multibyte numbers (pretty much all of them
| nowadays) the nice mapping disappears: u32{a,b,c,d} becomes
| {d,c,b,a} so that bit 8 is actually the 8th bit of byte d. So
| 0b 00000001 00000000 00000000 00000000 != 2^24.
|
| What I don't understand: why not just go all out little endian
| at that point? It seems like it would complicate circuit design
| as well given that an arithmetic shift needs weird wiring to
| properly work across little endian bytes big bits.
| jsmith45 wrote:
| CPUs don't need to keep the enregistered bits in any
| particular order. A little endian CPU could very much
| actually have the whole register stored in most significant
| bit to least significant bit, or vice versa, a big endian CPU
| could hypothetically even have the registered stored in
| little endian order, but that would be a bit odd.
|
| The part that matters is that references to smaller version
| of the same registers grab the correct bits, and that memory
| reads and writes write individual bytes in the little endian
| order (or big endian for big endian processors). Lastly bit
| order matters for any form of serial IO, but once again, it
| does not need to correspond to the internal ordering used by
| the processor in any way shape or form.
|
| The bit ordering in RAM within an individual byte also does
| not matter. If a CPU picked a random ordering of bits in a
| byte (like 46170325 instead of the logical 01234567 or
| 76543210 orderings) everything would just work as long as
| nothing else was directly connected to the memory bus. In
| practice even DMA devices are not connected directly to the
| memory bus, and all memory access goes through the the CPU's
| DDR memory controller, so it literally could pick whatever
| order for mapping bits to bytes that it wanted.
| zajio1am wrote:
| There is no real bit-endianity on the same level as byte-
| endianity, as there is no real bit-order. You could easily
| imagine bits to be perpendicular to byte memory cells.
|
| There is one place in computers where there is real bit-order,
| and that when it is represented on serial lines.
| colanderman wrote:
| If anything, bit order on most CPUs can be considered "little
| endian", because that's how CPU documentation numbers the bits
| (0, the first, being the lowest order). Not to mention bit-
| field insert/extract opcodes, like BEXTR on x86 [1] or UBFX on
| ARM [2].
|
| As another commenter points out, IBM is one of the few to
| reverse this and number bits in a big-endian order on their
| big-endian processors, with 0 being the most significant.
|
| [1] https://www.felixcloutier.com/x86/bextr
|
| [2]
| https://www.keil.com/support/man/docs/armasm/armasm_dom13612...
| runnerup wrote:
| Just adding onto this. Someone else already talked about the
| hardware level, where the bits for a byte arrive simultaneously
| over a bus.
|
| Generally this question is asked primarily by software people.
| It's worth noting that there's no way to access a bit in
| memory. The "atomic" level in modern computers is the byte. You
| can read a byte from memory, you can write a byte to memory.
| You cannot read or write a single bit.
|
| That is to say that it doesn't matter what endian-ness the bit
| order is. There's no way for the CPU to ever peek inside the
| RAM to see how the bits are arranged in the byte. The memory
| could store it in completely random order, with each block of
| memory shuffling the bits differently from every other block --
| as long as it send the data to the CPU in the expected fashion.
| bronzeage wrote:
| C has bitfields. These bitfields correspond to a specific bit
| order. I think in normal x86 it's little bit endianity - the
| first bit in a bitfield is the least significant. It's not
| specified in the C spec, but I've seen code depending on it
| nonetheless.
| ThePadawan wrote:
| AFAIK big-endian bit order makes the very very very low-level
| circuits easier.
|
| Want to compare two numbers? You can short-circuit (hah) as soon
| as the leftmost bit is different.
| addingnumbers wrote:
| Don't you just short-circuit as soon as any bit is different
| regardless of bit ordering?
| rowanG077 wrote:
| For equality yes. But not for ordering purposes.
| benlivengood wrote:
| In processors bits are in parallel, and in any arithmetic
| operation more-significant bits depend on less-significant bits
| because of carry, so you'd want to stream bits least-
| significant first.
| bruce343434 wrote:
| Why not just reverse the direction of the "comparison wiring"
| instead of the bit order?
| gopalv wrote:
| > big-endian bit order makes the very very very low-level
| circuits easier
|
| These probably invert pretty easily I suspect (the 1-bit bus
| with a latch would be the only order dependent thing).
|
| But as a human, it is definitely so much easier to write down 7
| on paper tape if the numbers match the big endian order.
|
| The big-endian bit order definitely made my "write binary on
| paper" exercises in college much easier to read back.
|
| The whole "arabic numeral" thing is accidentally visible there,
| where you fill numbers right to left if you want the decimal
| points to align.
___________________________________________________________________
(page generated 2021-07-06 23:02 UTC)