Path: utzoo!attcan!uunet!microsoft!bobatk From: bobatk@microsoft.UUCP (Bob ATKINSON) Newsgroups: comp.object Subject: Re: code blocks (aka closures) Message-ID: <55699@microsoft.UUCP> Date: 6 Jul 90 22:00:30 GMT References: <12396@june.cs.washington.edu> <1112@carol.fwi.uva.nl> <11011@alice.UUCP> Reply-To: bobatk@microsoft.UUCP (Bob Atkinson) Organization: Microsoft Corp., Redmond WA Lines: 49 In article <11011@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >In article , deutsch@parcplace.com (Peter Deutsch) writes: > >> Closures can be implemented with absolutely no overhead for places that >> don't use them, and relatively low overhead for places that DO use them. > >I won't repeat your description of the technique here, but I will say >that it looks like a nice one. It does have one disadvantage, >and that is that there are some machines that do not allow the >program counter to point into data space. Also, it is presumably >necessary to create these little pieces of code for those stack >frames that need them. See also Thomas M. Breuel, "Lexical Closures for C++", 1988 USENIX C++ Conference procedings for a reasonably detailed discussion of exactly the implementation technique that Peter describes. In the paper he points out that modifications of the technique will work uncooperative machines that prohibit the program counter from pointing into data space. I quote: "We can use another trick to implement lexical closures even on these architectures. We pre-allocate in instruction space an array of instruction sequences of the form: stub_n move location_n,R1 [ed: fetch static link] move (R1),SL move location_n+4,R1 [ed: fetch real routine address] jmp (R1) We use this array as a stack to allocate and deallocate closure stubs. A corresponding array of locations in data space holds the actual pointers to the code and the static link chain of the closures. These two new stacks behave essentially like the runtime stack. In particular, longjmp must be modified to restore the two stack pointers for the stub stack and the location stack appropriately." This of course statically limits the dynamic depth of the stack of closure activations. Bob Atkinson Microsoft