I am reading a file byte-by-byte.
Say for example i have this byte: 0x41 (0100 0001) represented in hex.
Now, I want the first three bits of this byte, i.e (010).
I can use bitwise logic to extract the first three bits, but my question is will the first three bits be independent of endianess of the machine.(i.e they can't be 001)?
Thanks,
Another way to think of this is that endianness only applies when you can read the components of an item individually - since you can typically independently read from memory the individual bytes of a 32-bit int, if you want to interpret those bytes as a 32-bit int you need ot ensure that the endianess of the architecture is taken into consideration.
Normally you can't read from memory the individual bits of a byte, so there really is no concept of 'bit endianness' as far as memory architecture is concerned (I'm sure there is at the hardware level, but not something you can see at the software level). A few areas where you might need to deal with (or at least be aware of) bit endianness:
the order that the compiler stores bits of a bit field is compiler dependent (and is not necessarily related to the endianess of the hardware platform - different compilers might order bit fields differently for the same platform - it's possible that a compiler could be configured one way or the other using command line options, similar to the way char might be set to be signed or unsigned). However, C bit fields really have nothing to do with hardware addressing.
some hardware architectures do allow you to address individual bits (the ARM Cortex M3 for example), so in this case you'd need to know how the architecture arranged for bits to be addressed if you were to use that feature.
if you're sending bits over a serial link - the hardware interface will typically specify whether the most significant bit or least significant bit is 'shifted' out on the wire first.
Endianness only applies to byte order, not bit order. The order of bits will be the same within the corresponding byte.
Yes, they will be the same.
Bit ordering inside bytes is generally only an issue when you're doing bit-by-bit I/O for instance when reading a stream of data sent over a serial line. Those really send a single bit at a time, so sender and receiver need to agree if bits are sent left-to-right or right-to-left, for each byte.
For files, and in-memory accesses, bit ordering inside bytes does not change.
For files, and in-memory accesses, bit ordering inside bytes does not change. I know one aberrant case with the avionics ARINC 429 word - if serialized directly, the bits in the label field are actually opposite the direction the bits of the other fields! (so the first bit in the line is actually the MSB for label, but the SDI, SSM and data fields have their first bits as the LSB).A bit confusing :-). Except in serial communication, the term "first bit" has no meaning, there are only left-most (most significant) and right-most (least significant) bits. If someone told you to extract "the first three bits" then give them a slap and ask what they meant. Even the term "Bit 0" is ambiguous, it often means the least significant, right-most bit (the 2**0 bit) but is almost as often used to mean the most significant, left-most bit in some bit-field. Which bit is the "first" bit in a byte depends entirely on what you are doing with the bits.
x & (1 << 0) or bittest(x, 0).The bitwise operators in C are defined to work on values. The expression 0x41U >> 5 will always give the value 2 (in binary, 010).
Bit order matters when a field uses part of a byte, or spans bytes starting or ending (or both) part way through a byte.
Example: 2 bytes of data first 235 (decimal) second 173 (decimal), aka hex EB and AD.
I want a bit field beginning at the fourth bit, through the 12th bit. So, skip over 3 bits, make a 9 bit unsigned integer from the next 9 bits.
I claim there are 4 possible outcomes:
byteOrder, bitOrder * bigEndian, bigEndian results in hex 0BA or decimal 186 * littleEndian, littleEndian results in hex 1BD or decimal 445 * littleEndian, bigEndian results in hex 05D or decimal 93 * bigEndian, littleEndian results in hex 1DE or decimal 478
I have seen the first 3 of these 4 in data. big, big, and little, little are easy to work out.
Hint for dealing with this.
If the byte order is big endian, write down bytes from left increasing to right. If the byte order is little endian, write down bytes from right increasing to left.
