Re: Support for Meta-Programming

[Stewart Greenhill <greenhil@murdoch.edu.au>]

At 09:37 PM 8/12/98 +0100, hartmut Goebel wrote:

>some month ago I promissed to build in support for Meta-Programming (aka
>module Ref). Some weeks ago I had had a look at the code and encountered a
>problem:
>
>Module Ref -- which implements important parts of Meta-Programming -- scans a
>structure like this:
>
>var    "a"  0
>var    "b"  4
>record "r"  8 MyFunnyRecordType
>
>Such a data area (byte stream) exists for every procedure (and module).
>Column three denotes the offset into the procedure frame (global vars for
>module).
>
>And this offset is the problem: I don't know any way to get this in C. Esp.
>since oo2c would not onfly have to know the size (sizeof), but also the
>alignment of the variables.
>
>Any suggestions?

I thought about this a while back when I was considering how to implement a
symbolic post-mortem debugger for OOC.

For objects on the heap, it shouldn't be too hard. Using the existing
meta-programming features, you can get the module and type name for heap
objects. It should be possible to find the definitions for these objects by
looking up the symbol files. This can be done using modules from the
compiler front-end (eg. SymbolFile.MOD, Data.MOD, etc).

There is a problem for module static variables and stack frames, because
although you can probably determine the names of the variables you can't
find their address at run-time. One way around this problem would be for
the compiler to allocate stack frames and static variables within records
which would have their own type descriptors (like heap records). The
definitions for the records would be in the symbol files, so it would be
possible to determine the addresses of variables. These records could be
maintained in linked lists so that they could be inspected at run-time. For
static variables it would be easy: the initialisation code for each module
would link its static variable record into a system-wide linked list. For
stack frames, the linking would need to be done as part of each procedure
prologue / epilogue. There would be a slight run-time cost here, but it
shouldn't require more than a few pointer assignments. Remember that Oberon
variables have to be initialised anyway, so the extra cost may not be
significant.

The problem with this approach is that it requires some fairly major
changes to the compiler's variable allocation scheme, which in practice
means more work for Michael. The advantage is a great deal of flexibility.
I would love to see Refs implemented, because this could be used as a basis
for a run-time debugger.

Cheers,
- Stewart