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.
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.
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.
I wonder if this misconception has more to do with the fact that programming languages define left/right bitshift operators and since left shift means making a number bigger, that implies the most significant bits are on the left (eg first in a LTR language).
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.
A long time ago TI's bit order was reversed from everyone elses. I remember because I wired one of their chips the way you would expect and didn't work right.
My opinion big endian should be intentionally unsupported.
There are other possibilities for numbering bits. I have seen PowerPC documentation where 32-bit registers have bits numbered from 32 to 63, with 32 being the most significant.
Bytes, words, etc. can also be stored and manipulated in the CPU, in which case 2-complement, rotates, shifts, etc. do have a directionality about them.
Certain bit-sliced microcode architectures can also impose a certain directionality for the bits.
Finally, serial communications and storage impose directionality upon the bit stream. (Anyone remember writing to magnetic tape?)
There is a sort of bit-endianity when you look at hex dumps of data, where you'd see something like "34 12" that represents the 16-bit value 0x1234 if the data was little endian.
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'.
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.
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.
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.
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.
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.
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.
There is one place in computers where there is real bit-order, and that when it is represented on serial lines.