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

[Richard Earnshaw <rearnsha at arm dot com>]

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

I'm only aware of one ABI where a C pointer is more than just the address 
of a function.  And this is an ABI issue, not a GCC one, so it isn't 
something that can be changed easily.

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

What is natural for a pointer depends entirely on where you come from.  If 
you come from a C background, then wasting time and space on a value that 
has no use is an anathema.

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

Using trampolines is a viable approach if you are prepared to deal with 
the issues it raises -- and lets avoid the discussion about security holes 
and enabling execution of the stack...

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

So in Ada it makes sense to make all pointers a couplet of values.  In C 
it doesn't.

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

Well, any processor/OS combination with execution protection on the stack, 
or any processor with harvard stacks and no user-level way of syncronising 
them is going to need help from the OS.  Pretending that trampolines will 
work on every platform without OS support just because the work on some 
doesn't lead us anywhere helpful.

R.