We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
There is a BUG in the compilation of a bit definition:
unsigned int bdata my_int; sbit bit15 = my_int ^ 15; sbit bit7 = my_int ^ 7; void main() { my_int = 0x8000; if(bit15) { // Here we shall not appear,as compiller // will be erroneous to check 7-bit of // a variable my_int instead of 15-bit // (as this variable place in memory in // little endian order) // ... } if(bit7) { // oops! we here! // ... } }
This is why there are also two ways people like to number bits (bit endianness) as well as bytes (byte endianness). Whichever method you pick, someone will be unhappy. Intel ordained the hardware's method of number bits and mapping bit addresses to bytes. Either the multi-byte sbit type has non-continguous bits when numbered sequentially, the bit numbers don't match order of physical bit addresses, or the sbit bit numbers won't match the number of shifts needed with the shift operators to get to that bit position.
"the bible states: One way is to refer to their address (i.e., 0-7FH). The other way is with reference to bytes 20H to 2FH. Thus, bits 0-7 can also be referred to as bits 20.0-20.7, and bits 8-FH are the same as 21.0-21.7, and so on. Erik
Bits in data of any width are always 0 - LSB, etc. up to MSB. And realization in hardware is only consequence. So attempt to invent something other looks absurdity. And to speak about linear addressing in general it is impossible - you in fact cannot declare a array of sbit[].