Hi,
I have the following code:
file1.h
extern const unsigned char c1;
file1.c
const unsigned char c1 = 25;
file2.c
const unsigned char c2 = c1 + 25;
According to the documentation www.keil.com/.../armccref_ciabaidh.htm both variables should be placed in ROM but this doesn't happen.
I found that the variable c2 is not put in ROM and RW-data increases by 4 bytes.
but when c1 is in the same module(same .c file) as c2, RW-data doesn't increase and RO-data increases instead.
Am I missing something ?
Thanks in advance :)
"Am I missing something ?"
The compiler can perform compile-time expression evaluations. But only when all parts of the equation have known values at compile time.
If c1 is in another module, then the expression c2 = c1 + 25 can not be computed while compiling file2.c. But if the assign to c2 can't be computed directly at compile time, but instead at run time, then c2 can't be stored in a read-only memory region.
Well, I tried enabling cross-module optimizations but it didn't help. It should be mentioned in the docs, thanks :)
Why should it be mentioned in the documentation?
It isn't a limitation of the tools, but a too high expectation by you.
But look at it further. Let's say that the compiler did manage to give the correct value of c2 with your cross-module optimization. Then you change your file1.c and give c1 another value. By standard compilation rules, file2.c should not be recompiled since it hasn't been changed, and neither have any #include file used.
So would you want cross-module optimizations to always recompile 100% of the program, just to solve this specific situation?
If a compiler documents cross-module optimizations, it will document what it does. Not what it doesn't do. If you buy a car, you will get to know that it has ABS, anti-spin etc. You don't get to know that it does not have an espresso machine and that it doesn't have automatic detection of speed cameras.
As far as expectations are concerned, this code shouldn't even be expected to compile at all --- not even with both definitions in the same translation unit.
The C language definition explicitly requires that initializers for static variables must be "constant expressions". While it may seem that values of other, const-qualified variables should be allowed in constant expressions, they're not. An implementation is allowed to accept other forms (and this one apparently does), but it is generally unwise to expect such things to just work, much less to behave exactly in any particular way.
That is one of the problems with all compiler extensions in existence. People get expectations that all other compilers must support it. And that the compiler should have supported even more language extensions not covered in the "must" list of the language standard.
Huge amounts of people look at gcc and then blame all other compilers for not "correctly" being able to compile their code.
The normal way for this would be:
enum { C1_VAL = 25, C2_VAL = C1_VAL + 25, };
And then _maybe_ create the c1 and c2 const variables but more likely just make use of the enum values.
As far as expectations are concerned ...
And there is the problem. In the real world, it is not uncommon for people within a group to have different expectations. For example, one person might think another is pompous and pretentious fool. Obviously, if they were to think that about me, they would clearly be wrong. For you, on the other hand, it would be different.