<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>> The CDC Algol 68 compiler had a trick for recognising expired scopes <BR><BR>
Hendrik -- but then again there is that heap allocation cost..<BR>
<BR>
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).<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 <BR> > rewritten for each platform, and can allocate the necessary <BR> > dynamically-genereated code on the heap (or, of course, on the stack, if <BR> > 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>
I don't think breaking the existing compatibility with C function pointers is good.<BR>
In fact, I dare suggest that C interop should be aided by the Modula-3 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 function pointers and Modula-3 function pointers might be viable. But you'd have to review all the "loopholes". Again probably a losing effort.<BR>
<BR>
As I've said a few times, I'm fairly content to leave this all alone. Maybe just to research "reliable" markers that cannot now or ever be confused for "real code". It's hard to make such a guarantee what with processors always evolving and gaining new instructions. If the constant could be dynamic, it could be an absolute reference to a particular reserved symbol. If you manage to call it incorrectly, that symbol would be a real function and raise an exception. This a) depends on their being a suitable addressing mode, ie: not PC-relative and allowing for large enough constants (possibly multiple instructions..big, wasteful) b) makes the check for the signature much more expensive since it'd have to read memory another time c) likewise for the formation of the closures. Could be that part of the signature is constant and part dynamic.<BR>
<BR>
Another idea would be to have a static check post-link run through all the code and verify the marker doesn't appear at the start of any function, if there is sufficient ability to read the code that way.<BR>
<BR>
Anyway, it's probably all fairly moot.<BR>
Just need to disassemble -1 on every platform now and every so often, to "lazily" "ensure" it is not valid code.<BR>
<BR>
Had I not hit the alignment fault I never would have discovered this stuff and we wouldn't be talking too much about it... :)<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Tue, 27 May 2008 11:45:51 -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 Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:<BR>> > I think I can shed some light on this, having spent some time making<BR>> > m3gdb handle the various operations on nested procedures. As for code<BR>> > that mixes M3 and C, I believe the following are true:<BR>> > <BR>> > - Within M3 code only, the closure system works correctly in all cases.<BR>> > This answers one of Jay's worries.<BR>> <BR>> As long as procedure-entry code can be guaranteed never to start wit a <BR>> word of one-bits. We do have some influence on this code, though, and <BR>> if necessary might be able to choose a different bit pattern on a <BR>> specific platform.<BR>> <BR>> > <BR>> > - For values of M3 procedure/C function pointer that are top-level<BR>> > (nonnested) procedures/functions, M3 and C code (generated by gcc,<BR>> > at least) are interchangeable. This answers another of Jay's worries.<BR>> > This will cover that great majority of cases.<BR>> <BR>> Yes. And in many cases, we will know statically that this is the case.<BR>> <BR>> > <BR>> > - Standard C has no nested functions. Gcc adds them as a language<BR>> > extension. Thus, only in gcc-compiled C code do we need to worry<BR>> > about nested procedures/functions between languages. (Do any other<BR>> > C compilers exist that also have nested functions?)<BR>> <BR>> Standard C has no nested function, and does not need closures. As a <BR>> result, Standard C can use simple pointers to represent function <BR>> addresses. The language extension retrofits closures using run-time <BR>> code generation. The way this is done (on the satck) is nonportable, <BR>> and we'd like to avoid that nonportability.<BR>> <BR>> The problem with seems to be just that you seem to want to use an <BR>> address of a function as a function pointer, and that just doesn't have <BR>> enough space in it to represent a closure.<BR>> <BR>> But why do it that way? Why not just let *all* Modula 3 functions be <BR>> represented by closures? Then you never have to test whether something <BR>> is a closure, it just always is. Top-level functions with no <BR>> environment just use a null pointer as environment -- and never use it.<BR>> <BR>> The only arguments for not doing this would seem to be <BR>> (a) the waste of space, making functions a little larger than necessary, <BR>> (b) and C compatibility.<BR>> <BR>> Now (a) is probably a nonissue, since the vast majority of functions <BR>> never have their addresses taken, are never passes as parameters to <BR>> other procedures, and so forth. So for the vast majority of functions, <BR>> you simply never have to build the closure.<BR>> <BR>> (b) might be a problem. The obvious trick is just to forbid passing to C <BR>> a non-top-level function. Since even the C programmers who devise <BR>> interfaces with callbacks realise that just a functino pointer isn't <BR>> enough, they usually provide a machanism for passing a void pointer to <BR>> additional information the callback might need. Nothing here puts <BR>> Modula 3 at a disadvantage relative to C. You can just use a top-level <BR>> function and let the programmer provide it with whatever it needs.<BR>> <BR>> But if it is deemed essential to provide actual single-pointer callback <BR>> addresses, this can be done by using a built-in function to convert a <BR>> procedure to a single-pointer callback. This functin will have to be <BR>> rewritten for each platform, and can allocate the necessary <BR>> dynamically-genereated code on the heap (or, of course, on the stack, if <BR>> possible on that platform). As for portability, it's certianly no <BR>> big deal to do this; compared with writing a platform-dependent code <BR>> generator (itself a requirement), this is not huge.<BR>> <BR>> > - M3's normal runtime check that precludes assigning a nonlocal<BR>> > procedure value will not detect a C-code-produced nonlocal value,<BR>> > thus the environment could indeed have disappeared if the programmer<BR>> > was not careful. However, gcc-extended C's nested functions have<BR>> > no protection against this bug when only C code is involved, so<BR>> > perhaps not detecting it in mixed M3/C is to be expected.<BR>> <BR>> We really can't protect against bugs in C code. If we could prevent <BR>> bugs in C, the market for it would be huge, and we'd be well advised to <BR>> consider that our main business.<BR>> <BR>> > <BR>> > - C code that attempts to call a function pointer value that was<BR>> > originally produced by M3 code as a nested procedure value will<BR>> > almost certainly crash at the time of the call. This is the only<BR>> > case that presents a significant problem. M3 code will not be<BR>> > able to give a nested procedure as a callback to a C library.<BR>> <BR>> Wherefor only in this case should we do run-time code generation.<BR>> <BR>> It has been argued that we don't need to protect against C programmers <BR>> going hog-wild and breaking their own code. Such is the nature of C.<BR>> <BR>> But, we can chack for some of it, it we are willing to go to the effort. <BR>> The technique used in the CDC Algol 68 compiler long ago might even <BR>> enable us to restrict the constraint on assigning nested procedures to <BR>> variables by a suitable run-time check.<BR>> <BR>> The CDC Algol 68 compiler had a trick for recognising expired scopes <BR>> using the garbage collector. Let's see if I can remember the details. <BR>> It involved special treatment for procedures whose addresses are taken, <BR>> and for the blocks that contain them. When entering such a block at <BR>> run-time, a word is allocated on the heap representing that scope. It <BR>> is filled with something relevant, such as the address if the stack <BR>> frame for the block, and the stack frame also pointed to that scope-cell <BR>> (as I'll describe it). Taking the address of a procedure involved <BR>> building a closure that points to that scope-cell. When leaving the <BR>> block, the contents of the scope-cell is wiped to some recognisable <BR>> invalid value. When entering the procedure the scope-cell will <BR>> still be around even if the scope is not. The procedure (this is inside <BR>> the procedure itself, not at the call) checks that the scope-cell has <BR>> not been wiped, and therefore is still valid. If valid, it contains the <BR>> necessary environment information. If not, break off execution.<BR>> <BR>> -- hendrik<BR><BR></body>
</html>