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! // ... } }
I have found such note in the C51 manual: ------------------------------------------- "The sbit data type uses the specified variable as a base address and adds the bit position to obtain a physical bit address. Physical bit addresses are not equivalent to logical bit positions for certain data types. Physical bit position 0 refers to bit position 0 of the first byte. Physical bit position 8 refers to bit position 0 of the second byte. Because int variables are stored high-byte first, bit 0 of the integer is located in bit position 0 of the second byte. This is physical bit position 8 when accessed using an sbit data type." ------------------------------------------- That only people will not think up to explain the absurds!
That only people will not think up to explain the absurds! it is crystal clear from your post that you have refused to even glance at the '51 architecture. Had you done so, the explanation would have been crystal clear. Well, since you refuse to study the '51 architecture, one comment Good luck, you will need it Erik for your sake I hope I'm wrong.
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
Do not stir bosh. Speak to the point. I have studied '51 architecture at once as soon as it has appeared. As it is the one-byte controller all other "wide" types of data are added by C-compiler. So C-compiler knows as data place in memory and it can take the necessary byte and to analyse necessary bit. I have declared the integer (16-bits) and I want at it 14-th bit. Instead of it I for some reason should read any ridiculous explanations and specify 6-bats. Unless it not absurdity?
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[].