Re: Extension compatibility policy

[Bernardo Innocenti <bernie at develer dot com>]

Joseph S. Myers wrote:
> On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
>
> > To move strings into program memory, there's a macro like this:
> >
> > #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
> >
> >
> > But this wouldn't work because __func__ does not work like
> > a string literal:
> >
> > #define TRACEMSG(msg,...) __tracemsg(PSTR(__func__), msg, ## __VA_ARGS__)
> >
> > C99's __func__ is supposed to work as if a "const char __func__[]".
> > The __FUNCTION__ extension could instead be made to work like a
> > string literal.   We could live without string pasting capabilities
> > if it helps keeping the interface between cpp and the C frontend
> > cleaner.
>
> How about calling decl_attributes from fname_decl so a target 
> insert_attributes hook can add attributes to __func__?  Would that suffice 
> to solve your problem?

It would be an excellent solution for myself, but portable code
might not expect __func__ to be stored in program memory.  This isn't
as transparent a a .rodata section.

Some compilers provide some sort of "fat" pointers, which of
course result in terrible code.  GCC's AVR target provides the
"progmem" attribute, but it requrires asm macros to fetch values.

The AVR is a Harvard processor, like many 8bit microcontrollers
and DSPs.  You need special opcodes to access data stored in
program address space, and this doesn't map well to C pointers.

Properly supporting this requires special variants of ANSI
string library functions such as memcpy_P(), strcmp_P(), etc.

A quick solution for the __func__ problem may be adding a
-mprogmem-func switch to the AVR backend.

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/