[M3devel] function pointers and comparison to	nil?	mis-typed	function pointers?
    hendrik at topoi.pooq.com 
    hendrik at topoi.pooq.com
       
    Wed May 28 14:00:30 CEST 2008
    
    
  
On Wed, May 28, 2008 at 07:04:58AM +0000, Jay wrote:
> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
> Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
>  
> These slow systems with JITs don't usually JIT "that often".
> They JIT like at one of:
>    module load 
>    first time a function is called  
>    first time a block is entered 
>  
> but not for subsequent loads/runs, at least not with the same process or "app domain".
>  
> > Until this discussion started, I never dreamed there was any
> > compatibility with C functino pointers except for non-nested 
> > procedures.
> > This all came as a surprise to me.
> That is all there is. You cannot pass a closure pointer off to C code 
> as a function pointer.
So the only programs that will be affected by the heap allocation to 
convert Modula 3 closures to C closures are programs which are currently 
illegal.  This makes it effectively have zero cost for existing code.
> You CAN pass gcc nested C functions off as such however.
Thus eventually we can expect to have to interface with libraries that 
expect nested C functino closures and don't pass an extra void pointer 
for environment.
> Opposing forces -- closures as dynamically sniffed pair of pointers 
> vs. closures as dynamically generated code.
> Ok, also nested functions that don't happen to use their parent 
> frames' locals probably interop.
I fact, everywhere we talk about the syntactically enclosing block, we 
should be talking about the most local enclosing block that declares 
names used in the function.
>  
> Ok, probably I should go and implement the *option* cm3cg -trampolines 
> and m3 -trampolines or somesuch.
>  
> I guess a pragma <* trampoline *> or <* c function pointer *> to let 
> source ask for it, but that's getting ahead of things, it's 
> "experimental" and probably just not desirable, but maybe just 
> interesting to get working...
>  
>  - Jay
    
    
More information about the M3devel
mailing list