This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] testsuite: Add new effective target keywords


BjÃrn Haase <bjoern.m.haase@web.de> writes:

> ...  I agree that it's possibly rather a technical issue: I meant 
> "nested_functions" to be more restrictive than "trampolines": In the case of 
> Harvard-Architectures with read-only program memory space (like AVR), it will 
> *allways* be impossible to implement trampolines.

Not that it matters for this patch, but this turns out not to be the
case.  A trampoline is a bit of code with three properties: 1) it sets
the static pointer to a dynamically determined value; 2) it jumps to a
function with a statically determined address; 3) you can take the
address of this piece of code and call it via a register.  You are
allowed to allocate the trampoline dynamically.  A trampoline is only
valid if the static pointer value is within the range of the current
stack pointer.

These properties mean that it is possible to implement dynamically
allocated trampolines.  You implement N of them in libgcc.  Each one
refers to specific global variables (probably in an array, of course)
to retrieve the static pointer value and the function address to jump
to.  The allocation routine returns the next available trampoline and
fills in the appropriate global variables.

The trickiest part is freeing trampolines which are no longer needed.
You can detect trampolines them by comparing the stack pointer to the
stored static pointer.  I believe it should be possible to do
automatically this via the check_stack instruction.  It will be called
when allocating the stack at function entry.  At that time you can see
whether there are any trampolines which can be freed.

While a naive implementation would be inefficient, my point is that it
is not impossible to implement trampolines on a Harvard architecture.
It's merely painful.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]