RAM, ROM and runtime calculation

What Stephan has said is absolutly right and things may change again when you download a compiler upgrade.

Besides, computing the runtime for any non-trivial function is very difficult - even when it is possible in theory.

By far the simplest and usually the best method is to use the simulator and the performace analyser to determine the time required to execute a function and to take an average over a large number of typical instances.

hi,
Thanks.
Iam computing the ROM, RAM and Runtime for both the cases
1. with optimization.
2. Without optimization.
With regards
Siva

Would you care to tell us why you want to know? This may make it easier to answer your question.

Stefan

Sounds like a homework question.

RAM would be variables. ROM would be the code and constants. The listing file (.lst) for a .c file generated by the compiler makes this fairly explicit:

MODULE INFORMATION:   STATIC OVERLAYABLE
   CODE SIZE        =   1395    ----
   CONSTANT SIZE    =   ----    ----
   XDATA SIZE       =     24      18
   PDATA SIZE       =   ----    ----
   DATA SIZE        =   ----      20
   IDATA SIZE       =   ----    ----
   BIT SIZE         =   ----    ----
   EDATA SIZE       =   ----    ----
   HDATA SIZE       =   ----    ----
   XDATA CONST SIZE =   ----    ----
   FAR CONST SIZE   =   ----    ----
END OF MODULE INFORMATION.

Program Size: data=117.6 xdata=12881 const=977 code=61452
LX51 RUN COMPLETE.  1 WARNING(S),  0 ERROR(S)

Hi,
Thank you very much for your reply.
First i want to answer Stefan's question.
Iam doing my masters thesis in which iam asked to optimize the interfaces (function calls, Macros) of embedded systems inorder to reduce the development cost.
It involves the following steps:

step 1.
Measuring the resources (RAM, ROM and Run time) consumed by different type of function calls.
for example
Function call with no return value.
Function call with return value.
Function call with one or more argument with return value and
Function call with one or more argument with no return value.

step 2.

I replace the functions by macros and measure the resources (RAM, ROM and Run time).

step3:
I repeat the above mentioned steps for different compiler and processor pairs and study the dependencies.

Step 4:
Provide a methodology or a set of rules which will help in minimizing the development cost.

For example:
I provide a table at the end of my thesis and the developer can look into the table and say for a fuction call with one argument this much amount of ROM, RAM and runtime is consumed.

Iam now in the first step.

with regards
Siva

Is there someone who is working in the same area. Please let me know.
Thanks.

--siva

"masters thesis ... to optimize the interfaces ... of embedded systems in order to reduce the development cost." (my emphasis)

Maybe I'm just being thick here, but how are you going to determine the effect on development costs?
The measurements you describe seem to concentrate solely on the generated code size?

Are you also considering the tradeoff of code size against execution speed?


"I provide a table at the end of my thesis and the developer can look into the table and say for a fuction call with one argument this much amount of ROM, RAM and runtime is consumed."

I think you may be taking rather a simplistic view here, I'm afraid. Optimisations like Common-Tail merging, Re-Use of Common Entry Code, Common-Block Subroutines, Linker Code Packing will make this extremely difficult - if not impossible - to determine! :-(

For the 8051 in particular, the number of arguments is only one factor:
* the types of the arguments can be far more significant;
* The Memory Model used makes a big difference;
* etc, etc, etc,...

And, of course, the efficiency of the code inside the function can have far more impact than just the call-return overhead!

You might be interested in running the Keil tools at different optimization levels and studying the generated code.

I think you'll find that the notion of "a function call" or "a line of code" is a bit hard to pin down. The "common entry" optimization, for example, finds bits and pieces of common function call sequences and turns them into subroutines, so two different function calls share the same setup code. (Sometimes I get the impression that any four bytes in a row that match get replaced by an ACALL/RET to save space.)

You might also want to consider the difference between passing registers in parameters and on the stack. The 8051 tools are a bit unusual in the way they handle the stack -- it's to be avoided, because the architecture doesn't cope with it well. Spilling parameters into memory has substantial space, speed, and reentrancy costs, and so there's a strong emphasis on keeping parameters in registers. A "function call with one parameter" with have vastly different costs if it is reentrant or not. Functions with multiple parameters are going to have varying results depending on the exact size and order of the parameters.