<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>> Id you can't write into dynamically-allocated code space, you may as <BR>> well forget about JIT compilers. Well, I suppose there could be <BR>> machines that can't have JIT compilers.<BR><BR>
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.<BR>
<BR>
These slow systems with JITs don't usually JIT "that often".<BR>
They JIT like at one of:<BR>
module load <BR>
first time a function is called <BR>
first time a block is entered <BR>
<BR>
but not for subsequent loads/runs, at least not with the same process or "app domain".<BR>
<BR>
> Until this discussion started, I never dreamed there was any <BR>> compatibility with C functino pointers except for non-nested procedures. <BR>> This all came as a surprise to me.<BR><BR>
That is all there is. You cannot pass a closure pointer off to C code as a function pointer.<BR>
You CAN pass gcc nested C functions off as such however.<BR>
Opposing forces -- closures as dynamically sniffed pair of pointers vs. closures as dynamically generated code.<BR>
Ok, also nested functions that don't happen to use their parent frames' locals probably interop.<BR>
<BR>
Ok, probably I should go and implement the *option* cm3cg -trampolines and m3 -trampolines or somesuch.<BR>
<BR>
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...<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Wed, 28 May 2008 02:14:24 -0400<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?<BR>> <BR>> On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:<BR>> > > The CDC Algol 68 compiler had a trick for recognising expired scopes <BR>> > Hendrik -- but then again there is that heap allocation cost..<BR>> <BR>> But only for the blocks closest-containing procedures whose addresses <BR>> are taken. That is relatively rare, and it will not cause heap allocation <BR>> for anyone that does not take addresses of nested procedures.<BR>> > <BR>> > This is also a step toward, like, heap allocated stack frames, except <BR>> > the garbage collected heap is only being used for its "lifetime <BR>> > features" and not its ability to store anything (other than <BR>> > lifetime/liveness).<BR>> > <BR>> > 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.<BR>> > I like the canonical Scheme example:<BR>> > <BR>> > (define make-adder (x) (lamba (y) (+ x y))) <BR>> > (define add5 (make-adder 5)) <BR>> > (add5 3) <BR>> > <BR>> > => 8 <BR>> > <BR>> > 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.<BR>> > <BR>> > > 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 <BR>> <BR>> > I think it's easy enough to generate the code, the problem is where to put it.<BR>> > Stack is not necessarily executable, heap is more expensive to allocate.<BR>> > But in this forum I'm always contradicted on that last point, so it could just be in the heap.<BR>> > Note that the heap isn't necessarily executable either.<BR>> <BR>> Id you can't write into dynamically-allocated code space, you may as <BR>> well forget about JIT compilers. Well, I suppose there could be <BR>> machines that can't have JIT compilers.<BR>> <BR>> Actually, if you're talking to C, you should be able to follow the <BR>> same restrictions that C uses.<BR>> <BR>> > <BR>> > I don't think breaking the existing compatibility with C function <BR>> > pointers is good.<BR>> <BR>> Until this discussion started, I never dreamed there was any <BR>> compatibility with C functino pointers except for non-nested procedures. <BR>> This all came as a surprise to me.<BR>> <BR>> > In fact, I dare suggest that C interop should be aided by the Modula-3 <BR>> > compiler generating "headers" for C.<BR>> > Really just a possible part of any "C backend". :)<BR>> > <BR>> > If the type system is strong enough..having two separate types for C <BR>> > function pointers and Modula-3 function pointers might be viable. But <BR>> > you'd have to review all the "loopholes". Again probably a losing <BR>> > effort.<BR>> <BR>> Just like C strings and Modula 3 strings?<BR>> <BR>> > <BR>> > As I've said a few times, I'm fairly content to leave this all alone. <BR>> <BR>> I, too. But I thought it ws worth pointing out that there is a <BR>> conceptually clean solution, especially since conceptually clean <BR>> practicality is one of Modula 3's hallmarks.<BR>> <BR>> -- hendrik<BR><BR></body>
</html>