Re: [avr-gcc-list] Improving in leaps and skips!

[Rolf Ebert]

On Wed, 2 Mar 2005 23:09:35 +0100, Björn Haase <address@hidden>  
wrote:

> > The point is: nested functions *do work* in AVR-Ada for what they are
> > typically used in Ada (limiting visibilty, enhancing code readability).
> >
> >      Rolf
> IIRC nested functions are completely dysfunctional for avr when using C.  
> The
> problem seems to be, that for any nested function gcc- c wants to  
> generate a
> trampoline (self-modifying code stub on the stack-frame) which is not
> possible with read-only program memory.

I tried the nested functiona again in Ada.  They are not completely  
dysfunctional, they are partly dysfunctional :-)

My statement above is still true.  Nested functions per se do work with  
current gcc and the Ada front end.  It does not work to take addresses of  
nested functions, though.  Obviously the generation of trampolines is  
deferred to the actual use of nested function pointers.


> If I understand correctly, the main use for nested functions is to  
> locally
> define small functions that could access the local variables of the  
> parent
> function and that could be passed, e.g. to library functions like  
> quick-sort.
> E.g. for sorting arrays that reside on the stack frame of the parent
> function.
> I have seen a thread stating that this "passing pointers to nested  
> functions
> to library routines" is a very popular coding style in ada.

The first part of what you reckon to be "main use" (access local variables  
of the parent) is ceratinly true, the second part (pass these local  
functions as parameters to other functions) is certainly not main use in  
Ada.  It didn't even exist in early Ada (ADa83), even in Ada95 the set of  
possible functions that accept function pointers is quite restricted.  It  
depends on the nesting level and the corresponding visibility.  It is a  
bit complicated to explain in this list.

A short term solution is to document that nested functions do not work.   
This "solution" might actually stay for quite while ...

Anyway, I think it might be a useful feature and it is part of standard  
GNU C.  I looked up the documentation of trampolines at  
http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html.  It states that the  
default behaviour of the corresponding macros does not work on processors  
that have separate program and data addresses like the AVR.  Propably  
nobody has ever ventured to write macros for the AVR yet.  My compiler  
knowledge is far too limited to try writing these macros myself.

    Rolf