[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