[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rolf Ebert
Subject: Re: [avr-gcc-list] Improving in leaps and skips!
Date: Sun, 13 Mar 2005 18:56:30 +0100
User-agent: Opera M2/7.54 (Win32, build 3865)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]