Re: Questions about trampolines

[Joern RENNECKE <joern dot rennecke at st dot com>]

Clifford Wolf wrote:

>    
>
>
> Some applications have recursions which go into a depth of 1000 and more.
> Some architectures have only a few k ram. Which "a size that works most of
> the time" would you suggest?
>
> It's ugly to have a static pool size. But it's intolerable to not allow the
> user to change that pool size easily using an option.
>  
Of course the user can change the size, by using a library with a 
different size.  But
there should be a sensible default.  The size of that default can vary 
from target to target.

> > The mmapped trampoline can be an absolute function call to some helper 
> > code that does the
> >    
>
> I am pretty sure that all processor architectures with such a strict haward
> design that it is impossible to generate dynamic code are MMU-less.
The application of the MMU-based scheme is more to accelerate trampolines by
avoiding cache coherency issues, without making allocation / 
deallocation more expensive.
In fact, since the code is already there, the initialization is cheaper 
than for classic stack-based
trampolines on pure von Neumann architectures.

FWIW, for processor-stack based trampolines. if we could guarantee that 
trampolines are the
only code that can be executed on the stack, we could avoid the 
memory-Icache coherency
issue altogether by allocating entire cache lines for trampolines on the 
stack, and filling them
up with trampolines (at least the code part), with a code part that does 
not change for any
given stack location.  I.e. after writing the code, we'd have to flush 
it to memory, but wouldn't
need to invalidate the Icache, since the only old code that could be 
there would be identical to
the code just written.