Re: How to handle qualified identifiers such as x.y in a Pascal-like language

On 6/24/2011 3:13 PM, George Neuner wrote:
> On Wed, 22 Jun 2011 11:47:19 +0100, Hans-Peter Diettrich
> <DrDiettrich1@aol.com> wrote:
>
>> noitalmost schrieb:
>>> What I don't quite understand is how to parse access to a variable in
>>> an outer stack frame. And I think this is similar to the problem of
>>> nested procedures (which I also don't quite know how to handle).
>>
>> First of all: local procedures using local variables in an *outer*
>> stackframe are problematic. Such a language feature deserves much
>> work, in detail when you also want to allow to use local procedures as
>> callbacks (procedure pointers). I'd drop that from my language.
>
> But doing so sacrifices quite a bit of power.
>
> In a Pascal-like language having strict stack semantics, the best way
> to handle non-local variables is to identify and move them all into a
> defined structure in the stack frame of the outermost enclosing
> function, then add a hidden pointer argument to all the inner
> functions and pass the address of the structure down the call chain.
>
> The same analysis allows for creating persistent closures by
> allocating the non-local variable structure on the heap instead of on
> the stack.
> [Of course, then you need other mechanisms to invoke the closures and
> clean up after them when they are no longer needed ... mechanisms
> which are beyond the scope of this discussion.]




well, I may elaborate, pardon if I am going outside the allowed scope
here...


one nifty trick I came up with in the context of my own stuff is:
allow using GC (Garbage Collection) for machine-code thunks;
create the actual function as accepting an extra argument to the
closed-over binding frames (chained heap-allocated structs, also GC'ed);
create a "closure object", which holds the captured frame, and re-calls
the actual function with the frame reference added to the argument list.


this process is fairly simple on x86 (with cdecl), but sadly gets very
nasty with the SysV/AMD64 calling convention (among other things, making
many such operations a good deal more expensive and error-prone than
their 32-bit counterparts).


even then, there are obvious deficiencies in my support of SysV/AMD64,
for example, a lot of my code doesn't handle variable argument lists
correctly, and technically the way literal structs are passed in my
stuff is just wrong (struct passing rules are like in Win64, involving
passing pointers to-be-copied memory, rather than decomposing them into
registers). but, grr...


I am still left to much wish Linux/... had adopted the Win64 ABI
instead, or at least something less complicated to work with. I am left
to consider later re-adopting an alternative calling convention in this
case, using SysV/AMD64 mostly only for external interfacing (possible:
AMD64 callee/caller-save status kept, but using Win64 argument passing,
and using name-decoration or name-mangling).




I technically supported closures in my C compiler (using the same syntax
as GCC's nested functions), but this feature wasn't really used, since I
mostly ended up using only "standard C friendly" features, or ones which
could be emulated via macros. later, my C compiler has mostly fallen
victim to bit-rot and my inability to effectively debug it (leaving me
to mostly use native compilers for C).


however, closures in the above form are still used, in a slightly less
nice-looking form, in plain C.


also they are used much more in my own BGBScript language, which is
mostly in the same language family as JavaScript and ActionScript (and
mostly conforms with ECMA-262). this language has closures as a default
feature.


the above mechanism (creating executable thunks) is mostly only used for
external interfacing though, as most internal calls are via
dynamically-typed "function objects", which are typically optimized some
by caching an "apply handler" (such as in class vtables/...), which are
called with the function-object and a pointer to the argument list or
similar (calling into a native ABI, such as SysV/AMD64, generally
involves "re-packing" the argument list at the last moment).


note: it is technically possible to call pretty much anything which has
an apply handler (note: most handlers are registered with type-specific
vtables, and there are many other types of handlers as well for various
operations).




how much of this would make sense in others' projects, I don't really
know...
[This strikes me as all stuff the Lisp community figured out in about 1980.
-John]

Return to the comp.compilers page.
Search the comp.compilers archives again.