Hi Steve.
Re:
That's odd. The Quadravox package has a number of good qualities,
but code size and speed are not amongst them. It isn't bad, but most
things work out 10% to 20% smaller using mspgcc or IAR 1.26B. That's
quite a lot on a small embedded processor. Some of my stuff which
keeps running out of CPU power with Quadravox runs with time to
spare using mspgcc. I wonder what is so different about your code
that you find such a different conclusion?
Dunno ... though it's safe to say that we have not "massaged" the
Salvo core code to perform better on any particular compiler.
The biggest code size differences comes the moment you include a
floating point calculation. Quite a few apps use just one or two
floating point calculations (e.g. for controlling the range of a
divide at the end of a long measurement process - I usually do
things the hard way, and avoid this). IAR is pretty good at only
dragging in only the library code it needs. Other compilers don't
seem to drag in the floating point stuff quite so incrementally,
with bloated results.
We don't use floating point in any of our benchmarks / projects.
Salvo is not in any way tied to anything FP, so there's not much
point in our exercising the FP capabilities of any of our supported
compilers.
I don't know how IAR v2.10A compares to v1.26B.
Someone I know doing comparisons found 2.10A produces significantly
smaller and faster code. 0-10% seemed to be the range in their
tests. I have 2.10A, but I haven't had a real reason to use it so
far. I found the bits of 1.26B code I have looked at an odd mixture
of good and bad, so there seems to be variable room for improvement
depending how many of the good and bad things your particular code
hits.
We now have v2.10A in-house, and it does appear to generate somewhat
smaller code than v1.26B. It also reports things differently in the
map file, and its libraries are incompatible with pre-v2 libraries
(to be expected, as IAR has made this clear in the past). Our next
release (v3.2.x, impending) will support it on a source-code level.
Since many IAR users are still at v1.x, we have to come up with a
viable solution to support v1.x and v2.x users, library-wise, and
that will take some thinking ... and work!
Regards,
--
______________________________________
Andrew E. Kalman, Ph.D. a...@pumpkininc.com
