In <200006051551.e55FppL18237@pincoya.inf.utfsm.cl> Horst von Brand (vonbrand@inf.utfsm.cl) wrote:
HB> "Khimenko Victor" <khim@sch57.msk.ru> said:
>> Horst von Brand (vonbrand@sleipnir.valparaiso.cl) wrote:
HB> [...]
>> HB> Take a look at a book on compiler building, where they discuss Algol-like
>> HB> languages. There are two major ways of implementing globals (variables in
>> HB> surrounding blocks):
>>
>> HB> - A static link in each activation record that points to the parent's
>> HB> activation record. When accessing a global variable, you walk the static
>> HB> links until reaching the correct stack frame. Here a function (pointer)
>> HB> is passed as a static link value plus a pointer to the code to run. This
>> HB> is slow, but simple.
>>
>> It's slow even for non-nested functions.
HB> Yes, but access to global variables is rare. And a smart compiler would
HB> cache the pointers to the activation records anyway.
Hmm. I talked NOT about globals. I've talked about "function is passed as a
static link value plus a pointer to the code to run". Thus your "pointer to
function" is not something fittable in register anymore, procedure call is
more complex, etc. Even if NO globals used at all.
>> HB> - A display, i.e., an array of pointers to the active stack frames
>> HB> for each level. The function is passed as a pointer to the code plus
>> HB> its display (part of it, really; not all has to be replaced). This is
>> HB> more efficient for global access, but hairy to implement (and
>> HB> probably impossible with HB> separate compilation, which can create
>> HB> displays of different depths in HB> different source files).
>> And once again you can not do this without affection call of "normal"
>> (non-nested) function.
HB> This _is_ the normal (only!) case in these languages. A "function pointer"
HB> in them isn't just a pointer to where the fuction starts. If everybody
HB> agrees on that, there isn't any trouble.
Pointer to function should be castable to void* (C++ mandates it). And if
you want different pointers in different languages of the same GNU compilers
family... Thnx, but no, thnx.
HB> In C you have to interact with code written by others and ABIs that
HB> specify that a function pointer is just the plain address where the
HB> function starts.
C has no such rule. C++ has.
HB> Can't retrofit Algol-like nesting into that except by some trampoline
HB> trickery or something even more bletcherous.
Yeah. And it was the point of the whole discussion :-) Trampolines are by
far the simpliest and most fast way to do what's needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:22 EST