[M3devel] function pointers and comparison to nil? mis-typed function pointers?

[Jay]

> 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.
You CAN pass gcc nested C functions off as such however.
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.
 
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



> Date: Wed, 28 May 2008 02:14:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:> > > The CDC Algol 68 compiler had a trick for recognising expired scopes > > Hendrik -- but then again there is that heap allocation cost..> > But only for the blocks closest-containing procedures whose addresses > are taken. That is relatively rare, and it will not cause heap allocation > for anyone that does not take addresses of nested procedures.> > > > This is also a step toward, like, heap allocated stack frames, except > > the garbage collected heap is only being used for its "lifetime > > features" and not its ability to store anything (other than > > lifetime/liveness).> > > > As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.> > I like the canonical Scheme example:> > > > (define make-adder (x) (lamba (y) (+ x y))) > > (define add5 (make-adder 5)) > > (add5 3) > > > > => 8 > > > > implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.> > > > > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > > > I think it's easy enough to generate the code, the problem is where to put it.> > Stack is not necessarily executable, heap is more expensive to allocate.> > But in this forum I'm always contradicted on that last point, so it could just be in the heap.> > Note that the heap isn't necessarily executable either.> > 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.> > Actually, if you're talking to C, you should be able to follow the > same restrictions that C uses.> > > > > I don't think breaking the existing compatibility with C function > > pointers is good.> > 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.> > > In fact, I dare suggest that C interop should be aided by the Modula-3 > > compiler generating "headers" for C.> > Really just a possible part of any "C backend". :)> > > > If the type system is strong enough..having two separate types for C > > function pointers and Modula-3 function pointers might be viable. But > > you'd have to review all the "loopholes". Again probably a losing > > effort.> > Just like C strings and Modula 3 strings?> > > > > As I've said a few times, I'm fairly content to leave this all alone. > > I, too. But I thought it ws worth pointing out that there is a > conceptually clean solution, especially since conceptually clean > practicality is one of Modula 3's hallmarks.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080528/70e1e0e6/attachment-0002.html>