BoostC Optimizations
some notes from the forum still to be formatted[edit]
The following post yeilded several real and unreal optimizations http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Incrementing[edit]
subtracting/deincrementing is faster than adding/incrementing
Valid? believed not to be true
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Avoid Division[edit]
not using division saves ~35 bytes
Valid? division is slow, but we think not by powers of 2, which are shifts ( if divisor know at compile time )
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Left vs Right Shift[edit]
Left Shifting is faster than Right
Valid? believed not to be true.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Function call in ISR[edit]
Calling a function in an ISR takes longer than outside an ISR
Valid? believed not to be true
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Function called Only Once[edit]
Never use a function for a single operation, you waste time calling and returning
Valid? believed not to be true.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Shift for Division[edit]
Use bit shifting instead of division for speed savings and possible ram savings
(shifting one bit right is equal to dividing by two, etc)
Valid? believed not to be true, optimizer is smart enough to do this.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Arrays and Pointers[edit]
Both arrays and pointers generate a lot of code. Use plain variables instead where possible.
I just saved a lot of bytes by reducing the number of index access on array vars.
a stupid and useless example:
char var[10];
for( i= 0; i<10;i++){
if ((var[i]==this) || (var[i]==that)) var[i]=somefunction(var[i]);
var[i]+=2;
}
if you need to have access on a particular index several times i'm using an extra dummy var.
char var[10], dummy;
for( i= 0; i<10;i++){
dummy= var[i];
if ((dummy==this) || (dummy==that)) dummy=somefunction(dummy) {
var[i]= dummy+=2;
}
}
something similar happens when you are working with struct variables.
Valid? We are pretty sure it is.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
ROM vs RAM[edit]
Write constants into ROM not RAM
Valid? In that you save RAM at the expense of ROM, normally you have more ROM than RAM.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Return Values[edit]
Do not return values from functions that you wont use/do not need.
Valid? We think so, seems like it must be.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
ROM vs RAM[edit]
Reuse common code or write a common function and call it will save huge amounts of space ( i suspect agressive opt in BoostC may negate this last but i've yet to test)
Valid? We think so, but even if not, it good coding pratice.
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
()?:;[edit]
i had forgotten about this one but the good old ()?:; (tri-unary?) function conditionally yields slightly smaller/faster code on every compiler i've ever used versus using if()else(); The gain varies from 1-3 lines of asm code, which, if in a high use test will amount to a conciderable savings.
The conditional aspect of this is that the fail function must do something it cannot be left empty or there is no value in using it and will actually result in longer code.
(test)?(result=1):(result=0);
VS
if(test)
{
result=1;
}
else
{
result=0;
}
i had forgotten about this one but the good old ()?:; (tri-unary?) function conditionally yields slightly smaller/faster code...
I tried that one out and there's no gain on SourceBoost C (for PIC16) on any optimization level.
For code like that, I would expect this:
result = (test ? 1 : 0)
to do better, but it doesn't, either...
with the asm disassembly, but it looks like i am wrong about the new version of
the compiler. i am glad to see that these are now the same as they are identical
chunks of code.
If i recall correctly, the reason they were different is that the if-else used to use two bit tests to determine logic, which is how you would do it if you had more ifelse tests.
Now i am back to using ?:; just for a cleaner look to code i guess. Thanks for testing that with the new version, it did not even occur to me that it may have changed
more in the post http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
do not get this one
Hmm it looks like the if-else might actually be one line shorter now ... altho it is just a lable line.
result= test&1;
Yes that would possibly work in this case as it is an extremly simple example.
But on the otherhand if you were writting code for an indicator light, say to
notify of an AD conversion, you could not use the return value as your test bit.
ie. if test = 4 that mask would fail but (test)?(result=1):(result=0); would work
since all non-zero/positives would set result.
i find this handy if you have more than one AD module on your device instead of using the flags as you can now build an AD FIFO cyclical stack or non-blocking time sensitive functions. (all that slow eeprom write stuff while your doing another conversion) ... hmm maybe i should add that example to handy functions ...
Post: http://forum.sourceboost.com/index.php?showtopic=2433&pid=9574&mode=threaded&start=#entry9574
Still More we are working on[edit]
Soft vs Hard Stack[edit]
Software stack is slower than hardware ( but deeper )
Valid? we think so.
Inline Functoion[edit]
Inline function does not really use call and return so is faster, but if called multiple time may take more space ( but for short funtions the call return... can take more space than the function itself. Would be nice if someone did measurements. BoostC Inline Functions
Valid? we think so.
Local vs Global[edit]
Local values vs global variables.
Issue not understood, local may require some stack heap management, but space should be recovered when function exits so local variable saves memory overall. Probably you should follow good pratices and use variables of th narrowest scope possible.
Links[edit]
Getting the Least Out of Your C Compiler Class #508, Embedded Systems Conference San Francisco 2001
