CODEWITHSUNDEEP
cembeddedsize
Andrew
Andrew

Reputation: 77

Fair comparison of code size

I have written two different C implementations of an algorithm that runs on an embedded processor (ARM). I would like a fair way to compare these two implementations in terms of code size, so when downloading the executable I get the following figures:

Implementation One

 .text size 55098 bytes
 .data size 2048 bytes

Implementation Two

 .text size 54598 bytes
 .data size 2048 bytes

The difference in the .text segment is 500 bytes, but in relative terms it is not a lot. The problem is, that this figure contains also boot code that is wrapped around the executable so that it can be invoked in standalone mode, ie., without an operating system on the embedded processor.

I am wondering if someone has an idea how I get the ACTUAL code size of the executable without all the bloated extra code.

Many thanks Andrew

Upvotes: 2

Views: 790

Answers (8)

tomlogic
tomlogic

Reputation: 11694

You could write an "Implementation Null" which just has a stub function that doesn't do anything. That will give you a baseline value to use in your comparisons.

(Size of Implementation One - Size of Implementation Null) vs. (Size of Implementation Two - Size of Implementation Null)

Upvotes: 0

supercat
supercat

Reputation: 81347

It can sometimes be difficult to figure the sizes of implementations in isolation, since some implementations require library routines to be linked in that others do not. If routine #1 is 300 bytes smaller than #2, but requires 500-byte library routine foo(), and routine #3 is 300 bytes smaller than #4, but also requires that same routine, then #1 in isolation effectively would be 200 (i.e. 500-300) bytes bigger than #2, and #3 in isolation would be 200 bytes bigger than #4, but #1 plus #3 would be 100 bytes smaller than #2 plus #4 (since the library routine would only be needed once).

This sort of situation can frequently arise if one produces a reduced-functionality (and reduced-cost) alternative to some library routine. If one can avoid the need for an expensive library routine, it can be worthwhile to write and use a simpler version. On the other hand, if code ends up using the expensive routine anyway, the simpler version may end up being superfluous.

Upvotes: 0

JayM
JayM

Reputation: 4938

If you are using the GNU tools, you can use the size tool. It will tell you the amount of memory used in each section by any object file. In your case, you'd need to make sure the code you want to measure is in its own file.

Here's an example of the output:

text    data     bss     dec     hex filename
9767       4    5184   14955    3a6b cfi_flash.o
1138       0     192    1330     532 cfi_mtd.o
 556       0     128     684     2ac mtdcore.o
3897       0       8    3905     f41 mtdpart.o

Upvotes: 0

tehnyit
tehnyit

Reputation: 1232

One possible way is to get your build tools to dump out a map with a finer granularity.

For example, if you are using the gnu set of tools, you could use run size on the .elf file and get a breakdown it based upon the object files in it.

You can also use objdump on the .elf file to get quite a detail map.

Assuming that the bootcode in your example stays constant between two overall implementation, use these tools should give you a better idea of which one has better code space efficiency.

Upvotes: 0

mouviciel
mouviciel

Reputation: 67919

In the end all the code will be downloaded, bootloader and OS included. So why would you like to exclude them from the measure?

A simple way to know the size of code you want to exclude it to compile with an application as simple as possible (e.g. main(){}). Then you just have to substract the obtained values from your next measures.

Upvotes: 1

Clifford
Clifford

Reputation: 93566

Your linker can almost certainly generate a MAP file (and may already be doing so) that will show (in minute detail) the memory usage details of all individual data and code objects, certainly down to the object-module level, and usually down to the individual function and data object level.

Upvotes: 2

2.718
2.718

Reputation: 435

  1. Your C compiler can usually produce assembly source code which you can examine.
  2. Another possibility is to look at the map file from the linker, it should give you the sizes of individual functions.
  3. You could look at the binary code with a debugger.

To get the asm output or map file(s), you need to specify the appropriate options to the compiler and/or linker. What these options are depends on which tool chain (compiler, linker) you use.

To get asm output from gcc: gcc -S -o hello_asm.s hello.c

Upvotes: 8

harper
harper

Reputation: 13690

You should defined what is part of the extra code. Hopefully you have written this extra code in another compilation unit. Your tool chain should have tools to detect the code size of that compilation units.

An most important, you should compare the code size with the availbale memory. It's not worth to reduce code size, if you don't have a requirement to fit the code in a specified area of memory.

Upvotes: 0

Related Questions