Re: Pros and cons of high-level intermediate languages

moss@cs.umass.edu (Eliot Moss)
Thu, 30 Jul 1992 00:08:32 GMT

          From comp.compilers

Related articles
[14 earlier articles]
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-25)
Re: Pros and cons of high-level intermediate languages jfc@athena.mit.edu (1992-07-25)
Re: Pros and cons of high-level intermediate languages scott@bbx.basis.com (1992-07-25)
Re: Pros and cons of high-level intermediate languages sewardj@cs.man.ac.uk (1992-07-26)
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-07-27)
Re: Pros and cons of high-level intermediate languages gat@forsight.jpl.nasa.gov (1992-07-29)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-30)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-07-30)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-08-02)
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)
[7 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: moss@cs.umass.edu (Eliot Moss)
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Date: Thu, 30 Jul 1992 00:08:32 GMT
Keywords: C, storage
References: 92-07-064 92-07-089

graham@maths.su.oz.au (Graham Matthews) said:


> (Hans Boehm) writes:
>>a) (the one I'd personally most like to see fixed) The treatment of
>>source languages that require garbage collection is tricky.


> I am not sure I understand what you are talking about here Hans. As
> far as I can see if the C code you produce is not safe in the presence
> of garbage collection then you are generating incorrect C code. There
> is nothing in C that makes it "garbage collection unsafe" even with a
> non-conservative garbage collection.


Suppose we have something like the following code:


int *p, *q;
int i;
for (i = 0; i < 100; i++)
p[i] = q[i];


Since C compilers are generally written assuming that allocated things do
not move during execution, we might get code like this for a machine
supporting two index registers in an addressing mode:


ld rp,p ; rp <- p
addi rl,rp,400 ; rl <- p + 100 * 4 (4 byte integers)
ld rq,q ; rq <- q
sub rq,rq,rp ; rq <- rq - rp
label: ld rx,0(rp,0) ; rx <- p[i]
st rx,0(rp,rq) ; q[i] <- rx
addi rp,rp,4 ; rp <- rp + 4
blt rp,rl,label ; loop if rp < rl (rl = the limit)


This appears to be perfectly legal code, yet it is possible that no
pointer to q exists, and we might gc (you might argue not in this case,
but I can add a call in the loop or something and fix that, or we can say
there are multiple threads and another thread causes gc).


This is the kind of subtle transformation that Hans was referring to. Note
that the transformation here improves performance by reducing the number
of items that need to be kept in registers from 3 (i, p, q) to 2 (p and
q-p) and requires only one increment around the loop. Strength reduction
and induction variable elimination definitely head this way.
--
J. Eliot B. Moss, Associate Professor
Department of Computer Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
--


Post a followup to this message

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