>>list of GCC is often borne out there, one has to grant that avr-gcc is
>>a dramatically superior product to any other offering for the target
>>CPU.
that's funny. before i read it, i was just about to observe that our Atmel
compiler
based on Plan 9's puts tables in program flash without any hints.
const alone wouldn't help anyway because the memory is accessed
using special instructions so the compiler and linker need to do
more analysis. otherwise the compiler does reasonable well given
that the chip is really an 8-bit micro. i think
the loader zl helps zc in some cases, and also monitors stack sizes.
it was important that the FFT and CC1000
tables go in program memory to save limited RAM,
although that feature was added fairly late.
we needed the atmel compiler for some work on motes.
i looked at gcc for it a bit initially whilst waiting for ours
but started to throw things or throw up; i can't remember which.
--- Begin Message ---
> To cap this the last time I did use a 16bit cpu and tried to do this,
> examination of the assembly proved the (name deleted) compiler was too
> dumb to take advantage.
Now, irrespective of which compiler Steve is referring to...
In the delusion that I may have to migrate to embedded systems when my
luck with system and network administration runs out, I follow the
traffic on the avr-gcc mailing list. Even though criticism on _this_
list of GCC is often borne out there, one has to grant that avr-gcc is
a dramatically superior product to any other offering for the target
CPU.
GCC is a monstrosity, but nothing else addresses all the issues that
it resolves. The cost is extremely high, but in my opinion it is
worth paying. I think GCC is closer to an organism than to a formal
translator and that may well be its strongest suit.
++L
--- End Message ---
