Re: Pros and cons of high-level intermediate languages

chased@rbbb.Eng.Sun.COM (David Chase)
Fri, 7 Aug 1992 19:12:17 GMT

          From comp.compilers

Related articles
[25 earlier articles]
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-08-03)
Re: Pros and cons of high-level intermediate languages rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-08-04)
Re: Pros and cons of high-level intermediate languages optima!kwalker@cs.arizona.edu (1992-08-04)
Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-04)
Re: Pros and cons of high-level intermediate languages nfsun!gchamber@uunet.UU.NET (1992-08-04)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-08-05)
Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-07)
Re: Pros and cons of high-level intermediate languages maniattb@cs.rpi.edu (1992-08-07)
Re: Pros and cons of high-level intermediate languages diamond@jit.dec.com (1992-08-10)
| List of all articles for this month |

Newsgroups: comp.compilers
From: chased@rbbb.Eng.Sun.COM (David Chase)
Organization: Sun Microsystems, Mt. View, Ca.
Date: Fri, 7 Aug 1992 19:12:17 GMT
Keywords: translator, design
References: 92-07-064 92-08-019

nfsun!gchamber@uunet.UU.NET (Glenn Chambers) writes:
>In the interests of getting the obvious out of the way, the easiest
>optimization is to allocate global and static local variables that point
>to GC'able objects in a special data area that the GC system knows about.


>Adding a '#pragma flush-registers' to deal with the optimizer seems to be
>the only actual extension to the language that I can see.


>Is there some simpler and cheaper technique I'm unaware of?


Yes, if you're using a conservative collector and your optimizer is "not
too smart" (but this raises the bar on how smart the optimizer must be).


Consider the following:


extern volatile void * __gc_sink; /* A reserved name not appearing in
                                                                          std-compliant programs. */
#define _GC_USE(x) __gc_sink = (void *) (x)


After *every* use of a pointer 'x' known (by the translator to C) to be
garbage collected, insert '_GC_USE(x)'. The optimizer does not get to
eliminate these, but (other than keeping a register for x) other
optimization proceeds relatively unhindered. In a post-pass over the
assembly language, or in the assembler itself (or object file generator
itself) the additional stores are stripped out of the instruction stream,
leaving only some register pressure (either from the address of __gc_sink,
or for the things stored into it).


The way that we (Hans Boehm and I) see this going wrong is if "x" is
reconstituted (say, from other induction variables) at the _GC_USE instead
of kept in a register. This is definitely not out of the question, but I
don't think this is in common practice yet. By not being excessively
clever with the location of _GC_USE (say, by placing it at the end of a
live range, instead of at each use site) you reduce the risk of this
happening (I think).


Long-term, what Moss et alii are doing is probably best, though it is
tough going.


David Chase
Sun
--


Post a followup to this message

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