siva surendar

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

7 years, 3 months ago.

LPC824: Const int question

Hello,

Our code has lots of integers 0,1,2,3 and 4 used for loop operation, setting flag etc. We think we have more than about 100 such places.

To save flash space and say to reduce processing time, is it better to define a integer like follows and use it in all places? 

const int int0-0;
const int int1=1;
const int int2=2;
const int int3=3;

If I have 100 such occurrences, will I save, say, .1kb of code space?

Best Regards Surendar

1 Answer

Erik -
7 years, 3 months ago.

I assume most efficient is to use hardcoded values. In order to keep tidy code you can use defines or enums to have good names. But in general I don't expect storing the integer values explicitly in flash will reduce your memory consumptions. If you just say: while(i < 5), it will compare with 5, so it will place that 5 in its flash with that loop. If you say while(i < int5) it will compare with the value of int5, so it will store the address of int5 in its flash with that loop, and in addition you also have to store int5 itself.

Accepted Answer

Erik Thanks for the quick response.

From the space standpoint

If I have the integer 5 hardcoded in 10 different places, is the compiler smart enough to know that they are all the same "5"s and so will unify them? Otherwise each 5 would be a stored in flash causing 10 bytes in flash instead of 1 if you use 

const int int5=5;

From a performance standpoint (even though this is only secondary for me)

I thought that if i say i<5, it will "push" i to a register, then push 5 to another register and then compare them. However if you did const it will be one push and compare.

Apologies for "pushing" on this. If its true and i can save space, I see saving around .1kb on my code. Dont want to make all the changes to const and find out it doesnt help :)

posted by siva surendar 02 Jan 2017

Problem is that if you do 10 compares to int5 instead of to 5, the compiler will still push int5 5 times to a register. Unless it is so close together in your code it will keep the value in its register. You can try a simple program to check it, but I really think instead of storing '5' Y times for each loop, it will store the pointer to int5 Y times for each loop.

posted by Erik - 02 Jan 2017

Erik,

I am ok with additional "execcution time". Based on what you say looks like it will save me FLASH SPACE (code size) if I use int1 insted of hardcoing 1. Am I right

Thanks a bunch for you patient listening to this topic

posted by siva surendar 03 Jan 2017

I would expect that storing the value 5 10 times would take up less space than storing it once and then referring to it each time. Those references will be in the form of a memory address which will take up as much flash space as the int will use so you end up using 11 dwords of flash, one for the value and 10 for pointers to it. My guess is that the compiler will avoid wasting the space and simply substitute in the value rather than a pointer to it in flash. For strings, longs or doubles it makes sense to store the value in flash and then include a pointer in the code, for int's or smaller it's probably more efficient to hard code the value directly.

Unless as Eric said the compiler is smart enough to load it into a register and keep it there for multiple uses.

It is easy to find out if there is any effect. Make a simple program using a const int and build it. Then change the const int into a #define (which will be identical to entering the number directly each time) and build it again. That will give you the difference between the two approaches. I doubt you'll see any difference.

posted by Andy A 03 Jan 2017

Well I don't think so, because instead of using 32-bit to store the value '1', it uses 32-bit to store the address to int1. You would need to test to be sure, since it is hard to predict how the compiler will optimize. But I would search for other possibilities to reduce flash size.

On top of that list would be: Do you use printf? If yes, do you really need it? If no, then unless you did other optimizations printf will still be included in the mbed lib. With some modifications you should be able to remove it.

Edit: Didn't see Andy's reply when I made this one. What he said :).

posted by Erik - 03 Jan 2017