Your reasoning about which end has interesting bits has no basis in how CPUs actually do any of their work The byte-ordering does not fundamentally affect how operations are implemented.
Us humans often find little-endian confusing because we write numbers big-endian. If you have the number 258 (0x102) in memory in little endian (which most computers use) 32-bit, it is hex 02 01 00 00, binary 00000010 00000001 00000000 00000000. If you bit-shift that one to the right without care, you end up with 00000001 00000000 10000000 00000000, hex 01 00 80 00, which is 8,388,609.
To fix it, write your digits also in little-endian order, so the first number is 10000000 010000000 00000000 00000000. Then the shift operations match expectations.
Your reasoning about which end has interesting bits has no basis in how CPUs actually do any of their work The byte-ordering does not fundamentally affect how operations are implemented.
Yes it does. Consider an MSB-first ordering, and you want to extract 4 bits to use as an integer or whatever: in the bit buffer, that would be "aaaaxxxx...", where "a" are the bits you're interested in. You'll need to copy from the bit buffer to the "work" register, then shift right in order to put them in the right place. Furthermore, to "eject" those bits, you need to shift left and insert from the lower bits, i.e. the bit buffer becomes "xxxx..." in its most significant bits.
With LSB-first, "...xxxxaaaa", the bits do not need any shifting --- they're already in the right place.
Just no. CPUs don't have an endianness on internal registers and operations - it only applies to memory access (and occasionally some simple conversion operations).
They are talking about bit-endianess here not the usual byte-endianess when they mention MSB-first and LSB-first.
The bit-endianesss you chose greatly impacts how your bit-reading loop will be implemented. In particular, if you want to use some bits, you want them in the low bits: if you write the value 42 into a 7-bit field, and then later I give you back (42 << 56) or something, you are going to be very confused: you expect to get back 42 (i.e., the return value equals 42, or to be pedantic the 7-bit field should be right-aligned in the uint32_t or uint64_t return value).
Us humans often find little-endian confusing because we write numbers big-endian. If you have the number 258 (0x102) in memory in little endian (which most computers use) 32-bit, it is hex 02 01 00 00, binary 00000010 00000001 00000000 00000000. If you bit-shift that one to the right without care, you end up with 00000001 00000000 10000000 00000000, hex 01 00 80 00, which is 8,388,609.
To fix it, write your digits also in little-endian order, so the first number is 10000000 010000000 00000000 00000000. Then the shift operations match expectations.