Estimating the memory size of a software

Question

I'm working on the development of Boot that will be embedded in a PROM chip for a project. I was tasked with making an estimation of the final memory size that the software will probably take but I've never done this before.

I searched a bit around and I'm thinking about doing the following:

• Counting all the variables, this size goes directly to the size total
• Estimating a number of line of codes each function will take (the code hasn't been written yet)
• Finding out an approximate number of asm instruction per c instruction
• Total size = Total nb line of codes * avg asm instruction per c instruction * 32bit

My solution could very well be bogus, I hope someone will be able to help.

Answer 1

On principle - You are on the right track:

You need to distinguish between several types of memory footprint:

• Stack
• Dynamic memory (malloc, new, etc.)
• Initialised variables
• Un-initialised variables
• Code

Stack is mostly impacted by recursion, local variables and function parameters.

Dynamic memory (heap) is obvious and also probably not relevant to you - so I'll ignore it for now.

Initialised variables are interesting since you need to count them twice - once for the program footprint on the PROM (similar to code and constants) and once for the RAM footprint.

Un-initialised variables obviously go toward the RAM and counting the size is almost good enough (you also need to consider alignment and padding.

The hardest to estimate is code or what goes into PROM, you need to count constants and local variables as well as the code, the code itself is more or less what you suspect (after adding padding, alignment, function call overhead, interrupt vector initialisation etc.) but many things can make it larger than expected, such as inline functions, library functions (many seemingly trivial operations involve such functions), casting etc.