It's a tricky thing.
In the early days of compilers, I'd just had done function pointer arithmetics
(subtract the start address from the start address of the following function)
but today with all these optimisations, the compiler can rearrange
everything. It' s not even sure whether it is not re-using the epilogue of a
different function at the end of the one you want to move, so the space between
its start and end does not contain all the function code.
One can circumvent this by placing the function into its own source file.
Placing the function into RAM section indeed is the only safe way to, well,
place it into the RAM section.
But this has several drawbacks.
First you must be absolutely sure that this part of the ram section is never
clobbered, as the function is placed there at start of the processor and never
refreshed.
This should be normal condition, but, well..., the stack is never far from your
data :)
Second, it uses RAM space. Always. And even if never used at all.
Third, if you have several of these functions, they ALL use ALWAYS their full
size in RAM.
I don't see, however, why functions in RAM shall not call any function in FLASH
(except when writing to flash is active)
Copying the function only if used allows re-use of a buffer that is currently
unused (such as an sprintf buffer or whatever) to temporarily store the
function, execute it and then continue with the required space free
again. It might even reserved space on the stack.
It also allows loading different functions to the same RAM space, when needed.
This way, the functions might be more specific and therefore smaller in RAM
even if they might take up more space in ROM all together.
One possible solution would be to look for the 'POP/RET' epilogue as delimiter
for the function-end. But it also requires a look into the LST file to ensure
optimisation hasn't messed-up things.
One can, however, apply the optimize attribute tot he function so it won't be
optimized or only optimized locally.
It would be nice to have GCC emit a global symbol such as '__sizeof_fname'
along with the '.size' statement. Shouldn't be a big thing to implement. But
still risky because of the optimisation problem described above.
Something like that is done with the following ASM hack:
extern const int __sizeof_myFunc;
void myFunc(void){
// code
}
asm (" __sizeof_myFunc: .short . - myFunc \n");
While this is not perfect, it generates a const value of the proper size of the
function (in bytes) right behind the function itself. (check the .lst file to
be sure)
You should still take care of any optimizations and it is best to place the
whole thing into a separate object file.
The declaration has to be 'extern' as the ASM line actually generates the
definition of the constant. But it only needs to be known where it is actually
used.
JMGross
----- Ursprüngliche Nachricht -----
Von: Rick Jenkins
An: [email protected]
Gesendet am: 14.November.2009 22:34:11
Betreff: [Mspgcc-users] Size of functions
Does msp430-gcc provide any systematic way, such as a generated symbol, from
which a C source file can determine the size of a function? I have a function
for field reprogramming, which is moved to RAM before use, and need to know
how many words to move.
