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.
I would like to to use the bit addressable memory range (bdata) with an index variable as in the following example:
#define SETBIT(I) WAIT_4_MUTEX; flags^I=1; FREE_MUTEX; unsigned char bdata flags; func () { unsigned char i; for (i=0; i < MAX_CELL; i++) { // do interesting stuff SETBIT(i); } }
This construction of coarse gives a lval error on the use of the SETBIT macro.
My current fall back are the macro's:
#define SETBIT(I) base |= ((unsigned char) (1 << I)) #define CLEARBIT(I) base &= ~((unsigned char) (1 << I))
But still have the feeling that I am wasting cycles on the shift operators in these two macro's and because this is within a mutex region the timing might become an issue.
Is there a better way to set/reset the i-th bit of a bit addressable variable ?
Only a very bad C compiler would not consider converting a switch() into a jump table if the case statements forms a suitably compact group.
in that case Keil is "a very bad C compiler" if you want to debug (no code overlay optimization) and a decent one if you do not care about using your ICE.
I have a strong suspicion that Keil has located some things in the optimizer that should be in the compiler, just to make the optimizer more impressive.
Erik
Several optimizing steps are part of the compiler and are run before the code generation. The optimization is performed on a statement/expression tree.
Some optimization steps are done after code has been generated.
With optimization turned off, the compiler will basicaly generate code for one statement at a time, since you have more or less requested that it shouldn't look at - and react to - statements before/after.
If you do generate the code one statement at a time and then just back-patch jump instruction targets, you will get code that is very easy to debug, but can be extremely inefficient. That isn't a fault with the compiler. Just the result of the developer asking for assembler code that has a 1:1 mapping with the source.
If the processor don't have a feature to process one single instruction and then return into debug mode, then the debugger must figure out beforehand which alternative in a jump table that will be taken, so it can insert a breakpoint at that specific target address - few flash-based processors would be capable of adding breakpoints to every possible case statement. Maybe Keil has decided that they don't want to use jump tables when all optimization is turned off.
I don't spend much time with debuggers, so I normally don't care about the generated code being harder to debug. Hence, I normally always use optimization just to make sure that all my code testing will be performed with the same optimization level I plan to ship with. In some situations, the developer don't have an option - the size difference between no optimization and optimize-for-size may be the difference between failed linking and a working application with space available for some future extensions.
It is very seldom good compilers produces broken code when otpimization is turned on, so if a program doesn't work as expected, it will normally be because of a direct bug in the source code, or a timing issue. Both can normally be located and solved reasonably fast by reading the source code, and maybe the addition of a debug printout or toggling an output pin around critical code sections.
Most times when people think they have found a compiler optimization bug, they have turned on an optimization step where they ask the compiler to ignore potential aliasing problems, and have then written code where the same variable may be accessed using multiple access paths - for example updating a global variable using both direct access and through a pointer.
there would be none, zero, nada issues with ICE debugging if the compiler used a jmp @. I can not understand why you need to use the optimizer (with the other ill effects) in order to have an efficient switch ststement.