WG: [avr-gcc-list] AVR-GCC question (Harvard Arch and C)

[Haase Bjoern (PT-BEU/EMT) *]

... Go ahead and compare the code size the different compilers generate. You'll 
probably end up with the decision, either to stick with gcc or take a device 
with twice the flash memory :-).

Yours,

Björn 

-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von stevech
Gesendet: Sonntag, 22. Mai 2005 23:21
An: 'Daniel O'Connor'; address@hidden
Cc: address@hidden
Betreff: RE: [avr-gcc-list] AVR-GCC question (Harvard Arch and C)

Split aka Harvard architectures are common in embedded.
Although GCC/Winavr is contorted into supporting this via piles of macros,
some C compilers are arranged to intrinsically support the architecture,
i.e., having two kinds of pointers (RAM and FLASH), and same for constants
and so on.

Examples include CodeVision AVR (excellent/low cost), IAR and the rest.
Really simplifies working with AVRs.

Steve

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Daniel O'Connor
Sent: Sunday, May 22, 2005 2:31 AM
To: address@hidden
Cc: address@hidden
Subject: Re: [avr-gcc-list] AVR-GCC question

On Sun, 22 May 2005 18:01, address@hidden wrote:
> > Perhaps it may be a good idea to have a separate set
> > of standards for embedded 'C'.
>
> I have programs which run on many quite different systems, including
> embedded SoC systems as well as huge UNIX clusters. While I am happy
> to get access to all the special resources (at least for the few
> time-critical parts), I am even more happy to have common base which is
> likely to work everywhere.
>
> I think that trying hard to push things into C compliance is very well
> worth it, the result being compliant implementation where possible and
> clear documentation of even slight divergencies for the rest.

I think the fundamental problem is that C wasn't designed for split 
architectures like the AVR so you are forced into using hacks to get it to 
work.

ie on say, a HC12, none of this is an issue because it behaves much more
like 
a "normal" system.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C




_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list