Dmitry K. wrote:
On Saturday 03 March 2007 07:57, Eric Weddington wrote:
Today, there is a bit of functions (memset, memcpy and
memcpy_P), which are in 2 variants: compact and speed.
This acceleration is very effective: a few of progmem
words give 10..30% speed increase. I plan to expand this
function list slightly.
Avr-libc compiles a speed variant for avr3 family only.
What about to add avr5? Is there any objections?
Hi Dmitry,
This brings up the overall issue of what should the goal be for avr-libc?
Speed, or size?
Speed is, IMHO, often an important aspect in embedded programming.
Faster code means lower clock frequencies for the same job, leading to
lower emissions and lower power. It can also mean more options
regarding the hardware (such as less stringent voltage restrictions).
Alternatively, it means the processor spends more time asleep, and
therefore use less power. All in all, faster code is good.
I still lean towards *size* as the number 1 priority for all code, for all
architectures and devices. When AVR compilers are compared, they are always
compared on code size, not code speed.
Size is the main priority when you are low on flash space - otherwise,
it is irrelevant. If your chosen AVR has 16k flash, then it does not
matter if the program code takes 2k or 15.9k of that flash. In
particular, for smaller devices, program space will be at a premium,
while for the larger devices, much of the flash will often be things
like tables or other data that is of fixed size.
There are only two things I have ever compared AVR compilers on -
features (where gcc wins), and "quality" of the generated code, which is
at least as much to do with speed as size. I can't see any reason to
generate poorer code just to look better on someone else's comparison
benchmarks, just because it is easier for them to give a code size than
do a proper comparison.
OK, I shall not change any compilation options.
Though a discrepancy remains between avr3 and avr5.
Nevertheless, I shall a little expand the list of functions
where this option is present. Certainly, it can affect a code
only in case of compulsory inclusion of this option. I shall
repeat, that it is a question only of small quantity of functions
which it is often enough used and where such optimization is
effective enough. For example (not commited now):
memset: 3.5 vs 6 clock/byte, cost= 4 words
memcpy,memmove: 5.5 vs 8 clock/byte, cost= 5 words
memcmp: 7.5 vs 10 clock/byte, cost= 6 words
strlen: 4 vs 5 clock/byte, cost= 2 words
Personally, I'd choose speed over size in all of these cases - the gains
are high and the costs low.
I would not be so categorical in an estimation of a priority
of the size. Eventually, speed is important from the very
beginning of the project, and the size starts to interest only
after overflow of memory.
For what it's worth, I agree with you fully, Dmitry.
mvh.,
David
Dmitry.
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
