On Thu, 08 Jan 2009 23:01:20 -0500, Norman Ramsey wrote: >> Algol 68 has a "scope restriction". Roughtly speaking, at no time can > > any value in a more global scope contain a pointer to anything of a > > less global scope. There is no effective way to test this except as > > run-time check. For the run-time check to be fast, pointers and such > > have to be big -- the have to contain ont only the address of the > > thing pointed to, but an easily-compared encoding of its scope. This > > has led most A68 implementers to ignore scope checking. Violating it > > isn't something a programmer does by mistake (not like indexing > > out-of-bounds, for example). So it works pretty well for everyday > > use. > > > > But it does lead to an insecure run-time system. The user should at > > least have the option to run in a secure mode. The two choices I seem > > to be left with are to implement full scope-checking, or to allocate > > everything that might be pointed to on the garbage-collected heap. > > As far as I know, no one has seriously implemented this option in a > > conventional programming language. > > > > Now one of the things that can be pointed to are labels; the pointers > > are, effectively, activation records with goto's in their procedures. > > The jump targets may, of course, be in procedure activations that > > have already been exited. > > I'm having trouble understanding here. What happens when such a jump > target is used?
Well, first of all, you can only get to this state in a program that violates the restrictions of the language, and has violated them well before the goto is executed. So the language definition says what happens in "undefined". But detecting this situation is expensive. I'd like further execution to be other than "indescribable chaos", to quote an early draft of the language definition. Given an activation record on the heap, I suppose I could mark it when it has been exited, and then test for this when I'm going to it. But barring a restrictin like this, it would be interesting to allow it -- the semantics would then be kind of like reusing continuations ins Scheme. Hence my remark > > Presumably you guys are familiar with Scheme. Any solutions? So I'll be content to wait for you to solve the remaining issues you listed: > We believe there is one remaining class of problems that C-- does not > solve but should solve. This class includes: > > - Copying a stack > - Splitting a stack into segments > - Inserting handlers between segments of a stack > > Applications include > > - First class continuations as implemented in Chez Scheme Is there something specific I should know about Chez Scheme here? As fat as I know, first-class continuations are standard in all Schemes. > - Perry Cheng's incremental garbage collector > - Work-stealing thread schedulers > - 'Parallel ready serial calls' as in Intel's Pillar language I don't know what these are. Presumably they are various uses of parallelism that don't involve any kind of preemptive scheduling. The first time I used this kind of code involved a lovely hack in C. To start a new "process", use a setjmp buffer to mark where you are now. Then call a function that has a huge local variable. That function calls the function that is the code for the new process. Every now and then, everyone calls the scheduler. A setjmp buffer provides the current execution point in each "process", and the scheduler simply picks one and longjumps to it. This worked on DOS, where memory was permanently allocated, including the part of the stack above the stack pointer. Of course, it would fail if one process's stack would bump into another's, but that didn't happen if you allocated enough space in the huge local variable. It wouldn't work in any system where the part of stack above the stack pointer is vulnerable to deallocation and destruction. > > We're hoping to tackle this set of problems next summer, after the POPL > deadline. > > > Norman > _______________________________________________ Cminusminus mailing list > [email protected] > https://cminusminus.org/mailman/listinfo/cminusminus _______________________________________________ Cminusminus mailing list [email protected] https://cminusminus.org/mailman/listinfo/cminusminus
