First, I am using 7.5 so it is an old compiler, but that is the way it is.
I have a number of bit variables that I am trying to pack into a byte. they are scattered all across the bit area
volatile bit var1; volatile bit var2; volatile bit var3;
char result;
The compiler won't let me do
result= (var1 <<1) | (var2 <<2) | (var3 <<4); the only way I have been able to get this to work is result= var1; result= ((((result << 1) | var2)<<1) | var3)<<1); This results in very inefficient code mov a,result mov r7,a mov c,v2 clr a rlc A orl A,R7; add A,ACC mov a,r7 mov c,var3 rlc A orl A,R7 add A,ACC mov a,r7 etc. as compared to: mov A,result mov c,v2 rlc a mov c,v3 rlc a would be much better. Does anyone know how this might be forced in C, without resorting to assembly? I'm wondering if because the ACC and PSW are evenly divisible by 8, whether or not you can use those and explicitly use the _crol_ intrinsic to accomplish this. I have not had any luck so far. In this case memory efficiency is more important than speed.
bdata unsigned char sample_result = 0; sbit var1 = sample_result ^ 0; sbit var2 = sample_result ^ 1; sbit var3 = sample_result ^ 2; main () { var1 = 0; var2 = 1; var3 = 1; sample_result = 0xFFu;
Generated code:
79: var1 = 0; C:0x070D C200 CLR var1(0x20.0) 80: var2 = 1; C:0x070F D201 SETB var2(0x20.1) 81: var3 = 1; 82: C:0x0711 D202 SETB var3(0x20.2) 83: sample_result = 0xFFu; 84: C:0x0713 7520FF MOV sample_result(0x20),#0xFF
bdata unsigned char sample_result = 0;
sbit var1 = sample_result ^ 0; sbit var2 = sample_result ^ 1; sbit var3 = sample_result ^ 2; volatile bit source_bit;
main () { var1 = 0; var2 = 1; var3 = 1;
sample_result=0xFF;
This is not what I am trying to accomplish.
The desired result is to PACK the 3 bits into positions in the result, which will be a bit mapped representation of the various bits scattered throughout bit (bdata) memory.
So if V1 =1; V2=0;v3=0 then result would be b00000100 or 0x04. so assigning sample_result = 0xFF would defeat the purpose.
I have about 17 bits free, so I tried it and it....
WORKS LIKE A BOSS! VERY nice. Thank you. generates a set of Var1=source_bit; mov c,source_bit mov (sample_result.0),c cut generated code down from x1B6 to x153 bytes. very significant savings.
"That's what bdata was invented for"
Yes, bdata is nice. But the question is if any C sequences will make the compiler itself make use of the concept with an intermediate variable, instead of forcing the developer to explicitly create a bdata tmp variable + 8 overlapping sbit variables.
Such as if any code sequence could get the compiler to make use of the accumulator, which just happens to be both bit and byte addressable - but which doesn't require the consumption of 8 dummy bits.
But maybe the Keil compiler has no such optimization rule, in which case it isn't possible to find any "magic" C sequence that will make the compiler in the background make a byte clear, multiple bit assigns and then store a byte to the final target address. Such an optimization rule would allow efficient bit packing to happen even for bytes that doesn't fit in bdata, without #define macros to hide all the sub-steps of the computation/assign.
By the way - it's rather brilliant how newer ARM Cortex chips emulates the bdata concept outside of the core in a language-neutral way.
cut generated code down from x1B6 to x153 bytes. very significant savings.
How much of that sentence would be appreciated by one of the multitude of C# fraternity?
Luv it :)
Well there was a wrinkle.
bdata unsigned char zz; sbit Bit7 ^ zz; ... compiler optimized things away. The compiler started by setting R7 to (state<<5) which is fine. Then the compiler issued a the correct bit set instructions. THEN it called sputchar passing R7 to it... Well this resulted in only the state being transmitted. zz= (state <<5); // take the state variable, and put it in the upper 3 bits of the byte Bit4=1; Bit5=0; sputchar(zz); So I changed the declaration to volatile bdata unsigned char zz; and got a syntax error near unsigned. And the Bit4=1; generates an invalid base address. WTF? Trying to find a way to force the compiler to reload zz into R7 before calling sputchar. In this case all worked fine.. zz=0; and followed by 7 Bitx = y statements. It reloaded ZZ into R7 before calling sputchar.... So something in the compiler is a bit to smart, gotta figure out how to force the load.... may have to try zz+=0; and see if that makes it reload.....
No, the compiler isn't too smart. It just fails to understand the aliasing between bit and byte - that there is an overlapping union of byte and bits. So the optimizer doesn't realizes that something have changed the byte variable, and thereby invalidating the value already in the register.
Will the compiler accept the volatile keyword if you move it after the bdata keyword?
I'll try that. what I did in the meantime, is to follow the last Bitx= line with one that does nothing, and consumes 2 or 3 bytes. sfrsave=SFRPAGE; Basically a data page move from an SFR. That forced the compiler to do explicit loads and saves. I'll try bdata volatile.. but I've always put volatile first.....
Well it swallowed that just fine, and I was able to take out the sfrsave=SFRPAGE line.
so why does volatile bit variable; work while volatile bdata unsigned char variable; does not work and bdata volatile unsigned char variable; DOES work.
That looks like a bug in the compiler to me.
pretty easy to demonstrate
volatile bdata unsigned char variable; sbit Bit7 = variable ^ 7; sbit Bit6 = variable ^6;
hope someone at keil will take note.
I'd actually like someone to verify whether or not this works on the current version of the compiler.
Might well be worth considering a small bit of assembler instead of trying to persuade the compiler to do something like this.
The order of attributes shouldn't matter, as long as we don't bring in pointers where the attribute binds to the pointer or the pointed-at value.
So volatile bdata xx and bdata volatile xx should both work.
But the optimizer really should also know about the aliasing between sbit and bdata since there is a hard-coded relation between them. And the whole idea with bdata is to get the aliasing effect, allowing the processor-specific one-bit instructions to be used. volatile isn't intended to solve aliasing issues, but to tell the compiler about asynchronous updates - i.e. that a task, ISR or actual hardware may change the variable state between two accesses.
I don't know if Keil has addressed this in later compilers, but
Per has it right.
The reason I tagged it volatile, was to force the compiler to do the load after the bit manipulations.
It worked in one order, but not in a different order. I think this is a bug.
For it to be a bug, it has to be doing something unintended. Unless you can find a document stating exactly what is intended you might find it very difficult convincing anyone else that it might be.
Well, the documentation claims: http://www.keil.com/support/man/docs/c51/c51_le_bdata.htm
The bdata memory type may be used to declare variables only. You may not declare bdata functions. This memory is directly accessed using 8-bit addresses and is the on-chip bit-addressable RAM of the 8051. Variables declared with the bdata type are bit addressable and may be read and written using bit instructions.
And then links to: http://www.keil.com/support/man/docs/c51/c51_le_bitaddrobj.htm which further claims:
Bit-addressable objects are objects that may be addressed as words or as bits.
This all breaks down, if the compiler doesn't understand the aliasing between the words and the bits, forcing the program to either only use word addressing or bit addressing.
There are two items at issue.
1. the order of volatile and bdata. volatile bdata char variable should work. because volatile bit variable works. So in my book that inconstancy is a bug.
2. The compiler fails to pick the bdata up, after modification, which is what Per is talking about. Again, the compiler has a bug in it, because logically it should be aware of the bits and where they are aliased to and understand that if an aliased bit is in the bdata area, and that byte was loaded into a register, then it needs to be reloaded again. I fully well expected that the compiler would pass the modified value to the subsequent function call, not that it would pass the original value to the function call.
It may not be a programming bug, but it certainly is a LOGICAL bug, as is the first item.
Inconsistencies in operation indicate a bug. It is quite probable, that the parser has a issue in parsing that line.
Whatever the case, I have managed to force the to do what I wanted it to. But having to change the order of volatile doesn't make sense.
" the order of volatile and bdata. volatile bdata char variable should work. because volatile bit variable works."
Note that bit is a data type, similar to char, int, float. While bdata is a storage attribute. And standard C doesn't have bdata, idata, far, near, ... that different platforms might need.
But it would be interesting to know what the compiler thinks about
static volatile bit x;
or
volatile static bit x;
static bit volatile x;
why not 'pack' in the definitions
u8 bdata packer sbit packbit1 packer^1
the above may be slightly wrong in the format I have not used the '51 for a while, but do remember using the above technique
Erik