[avr-gcc-list] AVR-GCC question

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

FYI,

There is some work under way to add functionality for several memory spaces to 
gcc. (Background is EEPROM support for Motorola UC, but this approach could 
readily be used for avr, once it is functional.) Difficulty is that one will 
need infrastructure from both back-end and front-end. I.e. it would need 
someone that has sufficient knowledge on the whole compiler. And even once it's 
functional, it would probably be a hard way to get a general consensus with the 
gcc-gurus to get this integrated into gcc. I don't expect a very-near-term 
solution, but there is work under way.

Yours,

Björn

-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Daniel O'Connor
Gesendet: Montag, 23. Mai 2005 13:08
An: address@hidden; Joerg Wunsch
Betreff: Re: [avr-gcc-list] AVR-GCC question

On Mon, 23 May 2005 14:23, Joerg Wunsch wrote:
> > ie on say, a HC12, none of this is an issue because it behaves much
> > more like a "normal" system.
>
> Same for the TI MSP430 controller.
>
> The C standard always (*) allowed it to have string literals in
> read-only memory locations, but they need to be compatible with the
> respective standard library functions, as well as with other string
> objects in RAM.

Hmm but it is very *useful* to put string contants in Flash even if they are 
more difficult to read :)

It would be nice if some form of polymorphism happened that allowed the 
compiler/linker to automagically pick the right function to handle a given 
data type though.

-- 
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