Re: [3.3 regression?] flag_hosted and back-ends

[dewar at gnat dot com (Robert Dewar)]

> I was thinking specifically of the GCC extension for C in this case, where 
> a single pointer-to-function value has to be magically expanded into the 
> address of a function *and* the address of a closure.  That pretty much 
> has to be done with trampolines and trampolines require support from the 
> OS on modern CPUs.

Only if you have a requirement that a pointer to a function must be a single
machine address. there is of course no such requirement in the C standard, but
it is certainly something that people expect. There is also an efficiency
tradeoff. If you use the more natural format for pointers (code pointer plus
static link) that is famkiliarly used in most languages with procedure
pointers, then calling ordinary top level functions requires an extra
load. In a language where nested procedures are used extensively, that
might be a reasonabloe trade off, but in GNU C, even though it supports
nested functions, it is very rare to see a program written in the style
you would expect for a language fully supporting nested functions, since
C programmers aren't inclined that way. So in GNU C, the extension is
typically used very lightly, and the trampoline approach makes sense even
from an efficiency point of view.

Of course in Ada, which does fully support nested procedures, the use of
nested procedures and functions is extensive, and it is much more common
to be calling nested procedures. As a result, it is probably the case that
in almost all programs, the use of trampolines is an efficiency hit, and
of course there is absolutely no reason in Ada why procedure pointers should
not be fat pointers.

As to trampolines requiring OS support, that's certainly not generally true,
if you look across current targets, the building of trampolines may or may
not require OS support.