2

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.

Daniel Costa
  • 27
  • 6
Leo
  • 500
  • 5
  • 15

2 Answers2

4

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.

Ofir
  • 8,194
  • 2
  • 29
  • 44
  • 1
    Regarding dynamic memory: many systems have a fixed heap size and you will be using as much RAM as this heap size no matter how much of it you are going to use. Regarding initialized variables: in C/C++ the double "footprint" only applies to variables with static storage duration, ie anything declared as static or global. Local (auto) variables are always stored on the stack or CPU registers, and there you are only interested in maximum stack depth, you don't have to count their RAM usuage, just the ROM constants which will likely be part of the program memory. – Lundin Oct 25 '11 at 20:10
2

On way of answering the question would be from experience or assessment of existing code with similar functionality. However there will be a number of factors that affect code size:

  • Target architecture and instruction set.
  • Compiler and compiler options used.
  • Library code usage.
  • Capability of development staff.
  • Required functionality.

The "development of Boot" tells us nothing about the requirements or functionality of your boot process. This will have the greatest affect on code size. As an example of how target can make a difference, 8-bit targets typically have greater code density, but generate more code for arithmetic on larger data types, while on say an ARM target where you can select between Thumb and ARM instruction sets, the code density will change significantly.

If you have no prior experience or representative code base to work from, then I suggest you perform a few experiments to get some metrics you can work with:

  • Build an empty application - just an empty main() function if C or C++; that will give you the basic fixed overhead of the runtime start-up.

  • If you are using library code, that will probably take a significant amount of space; add dummy calls to all library interfaces you will make use of in the final application, that will tell you how much code will be taken up by library code (assuming the library code is not in-lined).

  • Thereafter it will depend on functionality; you might implement a subset of the required functionality, and then estimate what proportion of the final build that might constitute.

Regarding your suggestions, remember that variables do not occupy space in ROM, though any constant initialisers will do so. Typically a boot-loader can use all available RAM because the application start-up will re-establish a new runtime environment for itself, discarding the boot-loader environment and variables.

If you were to provide details of functionality and target, you may be able to leverage the experience of the community in estimating the required resources. For example I might be able to tell you (from experience) that a boot-loader with support for Flash programming that loads via a UART using XMODEM protocol on an ARM7 using ARM instruction set will fit in 4k Bytes, or that adding support for loading via SD card may add a further 6Kb, and say USB Virtual Comm Port a further 4Kb. However your requirements are possibly unique and you will have to determine the resource load for yourself somehow.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thanks for your answer, some more detail about our project. it's a space project with ESA, processor used by the HW is a LEON2 processor (Based on SPARC v8 archi and instruction set). The Boot is commanded thru a MIL-1553 serial bus with Packet Utilization Standard commands. Basically the software manages the MIL-1553 protocol, executes command received and when receiving a specific command loads a binary image from EEPROM to RAM and start its execution. During start it also initialize and tests the whole HW – Leo Oct 27 '11 at 10:40