I declare a variable unsigned char bdata Kde in a.c.
[in file a.c] unsigned char bdata Kde;
[in file b.c] #include <stdio.h> ..... extern unsigned char bdata Kde; sbit testbit=Kde^1; void main(void) {......}
Oh, but if I had been able to turn off the optimizer I would have been able to see the constant expression that was being evaluated. I'd be pretty surprised to find any compiler that didn't remove the statement:
0x04;
Mark Odell writes: >Turning off the optimizer would not have helped you at all since it did not partake in your "bug". Oh, but if I had been able to turn off the optimizer I would have been able to see the constant expression that was being evaluated. This is the point as to why the optimizer was a barrier, and it seems a pointless barrier. >A good working knowledge of ISO C would have helped you, however. And your point is?...that the way it's been before is the best way? Robert
Turning off the optimizer would not have helped you at all since it did not partake in your "bug". Bypassing the C pre-processor would have yielded an error but you cannot bypass the C pre-processor. A good working knowledge of ISO C would have helped you, however.
"I'm still puzzling as to why I would want this." I think that was Jon's point - just because you can do something doesn't make it a Good Thing! As I said, you need to look at the preprocessor listing to see the text which the Compiler actually receives; the Compiler can't possibly give warnings about the input to the preprocessor, because it never sees that! Perhaps you need to start using lint, or similar?
Andrew, Thanks, the preprocessor listing could have exposed the problem sooner had I known about it. As far as being unable to turn off the optimizer, this seems like an undesirable idea. Why would the compiler writers have a problem with an option of NOT optimizing? I'm sure it would have saved me time earlier today. Robert
That's interesting, and I thank you for the explanation. I'm still puzzling as to why I would want this. Is there a lobby of C programmers who would be unhappy if they received warnings when they had their "if"s removed? Is this beyond the realm of state of the art?
sbit MODEM_RING = P1 ^ 4; #define MODEM_RING 0x04 // ring input
sbit MODEM_RING = P1 ^ 4; #define MODEM_RING 0x04 // ring input My question is, why was there no warning? Because #define is a preprocessor directive. These replacements are made before the compiler ever sees the C code. For the same reason, I can
#define if
Cuthbert, I see that your problem is documented and discussed on page 378 of the C51 User's Guide, User's Guide 09.2001. ...maybe it is not coincidence that I was reading that page earlier today. However, it turned out that my problem was that my sbit was being redefined and the compiler gave no warning, then optimized away all of the references to the sbit. sbit MODEM_RING = P1 ^ 4; #define MODEM_RING 0x04 // ring input My question is, why was there no warning? Another question, how do I turn off the optimizer? I tried setting it to zero but the code was still removed.
Yes - I think that's the inconsistency Mark was referring to
...repeating the sbit definition causes (if I remember correctly) a "multiple definition" Linker error. If and only if they are defined in a bdata variable. There won't be any linker error if we do:
/*Port.h*/ . . sbit bTest =P3^2; . .
I totally agree and sympathize. However, adding a feature such as
/* foo.c */ bit someBitVar = otherByteVar ^ 1; /* foo.h */ extern bit someBitVar;
The Buck Stops ... way over there! ;-)
Keil's doesn't appear a particularly Elegant Solution... From what I recall, the bit/sbit/bdata junk was what Intel introduced in the PL/M-51 Compiler. At the time the Keil C compiler was introduced, PL/M-51 was the de-facto standard compiler for the 8051. So, we adopted the Intel standard. These legacy language elements are sometimes difficult to kill-off or replace without breaking a lot of existing customer source code. Jon
"I just assumed consistency where there isn't." Yes; as both Graham and I have noted, Keil's doesn't appear a particularly Elegant Solution...
View all questions in Keil forum