Re: Garbage Collection in Ada

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.845732059@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>...As has been
>pointed out, this is not strictly correct code, but in the absence
>of a conservative garbage collector running around and deleting
>unrefrenced blocks (:-) will in fact work on any imaginable C
>compiler, ...

Not *quite* true -- there *are* C compilers that try to detect
non-ANSI-compliant use of pointers (for debugging purposes only, since
it's extremely inefficient), and you presumably would not be able to run
GIGI on such a compiler.  Of course GIGI is a special case -- when one
is committed to doing a bootstrapped compiler, one has a lot of freedom
to play games.  For example, I'm sure the GNAT front end would not
compile on any Ada compiler other than GNAT.  In fact, in some cases,
one version of the GNAT compiler won't compile under a different
(earlier or later) version of GNAT.

>The second answer is that in optimizing code, all sorts of transformations
>can occur, especially if you start doing high level optimization that
>can cause non-zero based arrays to appear as part of the transformations.
>This is the situation in which a compiler may end up fiddling with pointers
>in a way that is incompatible with a conservative GC. 

Oh, OK.  I didn't think that's exactly what "virtual origins" meant -- I
would call that "using algebraic transformations to represent pointers",
or "virtual-origin-like optimizations".  I guess it amounts to the same
thing.

>The use of a conservative GC system is, like the virtual origin coding
>in Gigi, something that probably works OK, even though it is requires
>some dubious fiddling (in particular the assumption that type casts
>from integer to pointer leave bits unchanged, something that the ANSI
>C specification could not require even if it wanted to).

They could have required that type casts of that nature don't lose
information, so they're reversible.  If they had wanted to, which they
didn't.

- Bob