Keep these entries coming, even if they only come around once a month. :D

— Simone

Anyhow, the way he taught us compilers, the... *thinks a bit* ... activation record (header data for every stackable or heapable thing) for a function/block instance kept two pointers: one to the dynamically surrounding block, and one for the statically surrounding block. For example, qsort’s statical father for the above example would be the global scope, while the dynamical father would be the block of sort_ints(). Comparison function would have sort_ints() as static father, and qsort as dynamical father.

This way, nested functions would be a piece of cake. comparison_function would be invisible in the global scope, and it could access any data in its statically surrounding block (sort_ints) through the static father pointer.

The theory of the insides of his compilers always looked so clean... No need for runtime generation of executable kludges!

So if I follow you correctly, this could mean that in a future version of Mac OS X nested functions in other compiled programming languages (like Pascal) may stop working?

-corbin

On processors which support disabling stack execution (like the Core Duo), your code can modify memory permission on a per-page basis. For example, you could write this trampoline and then use vm_protect to make the page containing the trampoline executable. Of course, since the trampoline is smaller than a page you’d also be making some code around it executable. The way to avoid this is to allocate a page-sized block on the heap for the trampoline, then make it executable and non-writable.

I’d love to see a GCC patch to do this for trampolines. It’d make -fnested-functions safe, whereas the current implementation turns off stack protection for the entire process.

One of these is trampolines, just as discussed here. It has the advantage of allowing interfacing with C and other bare-metal languages.

Another is ‘descriptors’, which seem to be an AIX thing and which I don’t understand.

A third is ‘fat pointers’. I think the idea here is that a pointer to a function is actually two pointers: a pointer to the code, and a pointer to the stack frame to use for its lexical scope. It’s not obvious to me whether that would affect how every function is called, or if it could be limited to functions called through function pointers. It would also have the weird side effect of making function pointers twice as big as data pointers; would that be within the C spec? Even if so, it would break a lot of peoples’ assumptions.

Function pointers were implemented as pointers to the Tvector, and a function pointer call (*Ptr)(foo) would be treated by calling the equivalent of __ptr_glue(Ptr, foo). (In answer to the question about the C spec: pointers may be different sizes, as long as void * is the size of the biggest pointer type; but this indirection makes it a non-issue.)

Normally a Tvector would just be two 32-bit words in the code fragment’s data section. However, the fact that the address of the Tvector was put in a register before the call meant that the Tvector could contain additionall arbitrary fields, and as the Tvector contained no executable code it could easily be built on the stack, even with protection. A nested function code would then generate code along these lines:

typedef struct { void *entryPoint, *TOC; } TVector;
typedef struct { void *entryPoint, *TOC; char *parentStack; } NestTVector;

void outer_function(void) {
int x = 0;

TVector tv_inner_function;
NestTVector tvn_inner_function;

tv_inner_function = (TVector *)&__outer_function__inner_function;
tvn_inner_function.entryPoint = tv_inner_function.entryPoint;
tvn_inner_function.TOC = GetRTOC();
tvn_inner_function.stack = GetStackPointer();

extern_function(inner_function);
}

void __outer_function__inner_function(void) {
NestTVector *tvn_inner_function;
tvn_inner_function = &GetR12();

*(int *)(tvn_inner_function.parentStack + offsetForX)++;
}