Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have just started using SDCC for PIC (14 & 16) and I notice that const static int (and variants) are not being optimised.
Specifically const static ints should be treated as compile time constants and should not be allocated an address.
I created the following simple program to demonstrate -
const unsigned char VALUE2 = 24;
unsigned char test( unsigned char ch )
test( VALUE1 );
test( VALUE2 );
This generates the following assembler
_main ;Function start
; 2 exit points
; .line 25; "test1.c" test( VALUE1 );
;genAssign from CODESPACE
; .line 27; "test1.c" test( VALUE2 );
MOVF low (_VALUE2+0),W
MOVF low (_VALUE2+1),W
;;1 MOVWF r0x1001
; exit point of _main
As you can see the first call of test, using the #defined value just loads the literal value into W, but the second call generates 10 assembler statements (actually 9 instructions because in this example the PAGESELs are null).
I would expect the compiler to generate the same code (apart from the literal value) for both calls.
The very few occasions where this optimisation is not helpful occur when the value must be passed to a function that requires a pointer (and therefore an address). But there is no good reason to pass a constant scalar value by reference rather than by value since the function can't update the value anyway.
Last week I found out that GCC for ARM7 does not even put a const char array in global space but places it on stack instead. I had to explicitly mark it static to get my stack space back. At least SDCC got that right.
The treatment of const static variables is an interesting problem, and in my opinion it is reasonable to implement them as real stored variables. Correctness is more important than speed, and optimisations can be very hard to verify. It is unfortunate that the PIC architecture is so poor at handling your example.
NB A fully optimising compiler would remove all your code.
Thanks for your reply Oliver, and obviously correctness if paramount. However, I fail to see how treating a const static - by definition an unchangable value - as a compile time constant can affect correctness. Furthermore, performance is often an issue in embedded systems and code compactness even more so making this kind of optimisation more important in PICs than in large multiprocessor systems.
Further, the C++ standard ( yes I know we are talking C here but they are interested in correctless) encourages the compiler to replace class level static consts with compile time constants and not to allocate memory unless the address is taken. In addition, as I mentioned originally, all the several compilers I use professionally do in fact replace all static consts with compile time constants wherever possible, even if read-only memory has been allocated so that a call be reference can be compiled.
In fact, if a static const value is stored as a real variable a program or compiler error could cause the const value to be changed which could cause unexpected behaviour that would be impossible to debug because the "bad" code could be in a completely unrelated area of the program to that exhibiting the problem (because of the modified "constant").