Re: arm-none-eabi, nested function trampolines and caching

[David Brown <david.brown@hesbynett.no>]

On 29/11/2023 08:50, Matthias Pfaller wrote:
> On 2023-11-28 19:00, David Brown wrote:
>  > Can I ask (either or both of you) why you are using are using nested 
> functions like
>  > this?  This is possibly the first time I have heard of anyone using 
> them, certainly
>  > the first time in embedded development. Even when I programmed in 
> Pascal, where
>  > nested functions are part of the language, I did not use them more 
> than a couple of
>  > times.
>  >
>  > What benefit do you see in nested functions in C, compared to having 
> separate
>  > functions?  Have you considered moving to C++ and using lambdas, 
> which are more
>  > flexible, standard, and can be very much more efficient?
>  >
>  > This is, of course, straying from the topicality of this mailing 
> list. But I am
>  > curious, and I doubt if I am the only one who is.
> 
> - I'm maintaining our token threaded forth interpreter. In the inner 
> loop there is a absurdly big switch for the primitives. I'm loading rp, 
> sp and tos into local variables. pushing, popping  and memory access is 
> done by nested functions (checking for stack over and under flows, 
> managing tos, access violations, ...). Of course that could be done by 
> macros. But when I'm calling C-functions from within the switch I'll 
> sometimes pass pointers to the local functions (e.g. for catch/throw 
> exception handling).
> 
> - When calling list iterators, I'm sometimes passing references to 
> nested functions
> 
> - When locking is necessary and the function has multiple return points 
> I'm doing something like:
> 
> void somefunction(void)
> {
>    void f(void)
>    {
>       ...
>    }
>    lock();
>    f();
>    unlock();
> }
> 
> I know, in a lot of cases I could just define some outer static function 
> or use gotos. But to my eye it just looks nicer that way. In most cases 
> there will be no trampoline necessary anyway. Its not used that often 
> and we could probably get rid of it in most cases by using macros and ({ 
> ... }).
> 

Thanks for that.

I can appreciate that local functions can look nicer than macros or goto 
spaghetti.  In simple cases (which is probably the majority for your 
usage), the local functions will be inlined and will give pretty much 
exactly the same code as you'd get for macros, outer static functions, 
or other methods.  But I'd be very unhappy to see trampolines here, as 
you will need for more complicated cases.  The overheads are not 
something you'd want to see in the inner loop of an interpreter.

AFAIUI, the reason the compiler has to generate trampolines here is to 
make a function that has access to some of the local variables, while 
being shoe-horned into the appearance of a function with parameters that 
don't include any extra values or references.  If you were, as an 
alternative, to switch to C++ and use lambdas instead of nested 
functions that all disappears precisely because lambdas do not have to 
be forced to match the function signature - the generated lambda can 
take extra hidden parameters (and even extra hidden state) as needed.

Of course it's never easy to change these kinds of things in existing 
code.  And it is particularly difficult to get solutions that work 
efficiently on a wide range of compilers or versions.

David