Re: Pros and cons of high-level intermediate languages

nfsun!gchamber@uunet.UU.NET (Glenn Chambers)
Tue, 4 Aug 1992 11:43:33 GMT

          From comp.compilers

Related articles
[23 earlier articles]
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-08-04)
Re: Pros and cons of high-level intermediate languages kanze@us-es.sel.de (1992-08-04)
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: nfsun!gchamber@uunet.UU.NET (Glenn Chambers)
Organization: Intelligent Technology Group, Pittsburgh, PA
Date: Tue, 4 Aug 1992 11:43:33 GMT
References: 92-07-064 92-08-004
Keywords: translator, design

>[Somebody suggested that it might be possible to define some extensions to
>C that would make it easier to garbage collect. Any thoughts? -John]


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.
Auto local can be dealt with by maintaining two stacks: non-pointer and
pointer, at a relatively minor cost.


This leaves, of course the minor problem of finding pointers inside of the
pointed-to structs. The much nastier problem of finding them inside of
unions is probably avoidable in the current case, as we're talking about
'C-as-intermediate-code', and the parent code-generator can presumably be
coded not to use unions.


Adding a '#pragma flush-registers' to deal with the optimizer seems to be
the only actual extension to the language that I can see. One would put
this just before a call to any function that could perform memory
allocation. Absent some kind of global optimizer, this would, of course,
be all of them, with a possibly non-trivial loss of performance.


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


Post a followup to this message

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