Ok, maybe I could change IDE to use -O2 instead, and maybe it generates better code. Or is the an optimization #pragma expression for GCC I can use?
I have Teensy 3.0 as well but I like to have this code running nicely on Uno for the sake of the microcontroller optimization challenge and exercise (: I haven't been writing asm for quite some time either, but maybe it's time to get a bit familiar with AVR asm.
JarkkoL:
I have Teensy 3.0 as well but I like to have this code running nicely on Uno for the sake of the microcontroller optimization challenge and exercise (: I haven't been writing asm for quite some time either, but maybe it's time to get a bit familiar with AVR asm.
I haven't done it myself but you could try altering your build process to use the later avr-gcc program.
As far as I understand, C has no concept of the idea that the result of an operation can be a different type than the operands (as in "an 8x8 multiply gives a 16bit result.") So I think that...
res += (smp * vol) >> 8;
has two possible interpretations:
smp and vol are 8 bits, and are promoted to 16bit quantities before the multiply, giving a 16bit result. (this is what is happening, right?)
smp and vol are 8 bits, the result is 8 bits, shifting right by 8 bits gives zero, and the statement is a no-op. (this is not what you want, is it?)
You wanted "smp and vol are 8 bits, the result of a multiply is 16bits, give me the high 8 of those 16bits" - C is not going to do that.
"mixed-size math" remains one of the areas where assembly language retains a big advantage over C.
Except in special cases, no compiler can optimize for both speed and size at the same time. In addition to compiling for speed and compiling for size, and third thing people need to choose is whether the time spent doing the compilation is more important than either the time it takes the executable code to run or the size of the code.
And as mentioned in other posts, the GCC shipped with the AVR is based on a release from 5 years ago.
I updated the compiler to the latest one from Atmel (4.7.2) and it does much better job with optimization. For multiplication it's now also using the "mulsu" instruction instead of 3 muls:
It works and I just realized I have stopped performing step #8 so I suspect it can be removed.
Step #5 is only necessary if you want to preserve the old version (which I only do so I can support the Tiny Core).
A few folks claim avrdude from the Arduino download is necessary but I have not had any problems using the WinAVR / Atmel version. Maybe it's necessary for Mac / Linux users.
That should be a sticky somewhere.
No doubt!
I'll never remember that when I actually need to do it.
In my case, I just keep copying / moving the "good" avr folder to wherever I need it. I've done it so many freakin' times I can do it in my sleep (and may have).
For what it's worth, I have been using the WinAVR version for a few years and the Atmel version for a few months with no regrets.
I don't believe their claims. The newer avrdude works just fine for me.
I run avrdude that I build myself from the avrdude repository.
I use linux, but I have also built it for other folks that still use Windows.
It works just fine on those two platforms.
I also patched avrdude to get the AVR dragon to work with the IDE and the optiboot makefiles
to burn a bootloader.
(There are small patches that could be done in the IDE or the optiboot makefiles to work
around the avrdude issue, but I've not been able to get either of them to make the changes
so I just fixed it in avrdude where it really should be fixed anyway)
One thing to note about the newer avrdude, is that
it is MUCH faster at burning a bootloader because it knows how to skip over unused regions
Example:
0.5 seconds vs 30 seconds on USBasp to burn a new bootloader.
With the old avrdude the entire flash gets burned even for a 512 byte bootloader.
[I don't believe their claims. The newer avrdude works just fine for me.](http://I don't believe their claims. The newer avrdude works just fine for me.)
OPINION:
I do not use the stock version either... But I have a virgin installation on another PC just for sanity testing...
We more advanced forum members must realize that a noob/newbee/joekool might just do the upgrade because they think they must have the latest-greatest. Such actions could go terribly wrong if any of the arduino-centric code breaks. Users look to the forum for support, we never ask about environment changes and tool versions.
In the context of this post, everyone seems to know the framework. I just wanted to point out:
DO NOT UPGRADE TOOLS UNDERNEATH THE ARDUINO PROGRAM DIRECTORY IF YOU EXPECT FORUM SUPPORT SERVICES
It is difficult walking folks through Arduino code issues without introducing compiler-linking -version concerns. At least for me.