Re: Pros and cons of high-level intermediate languages

graham@maths.su.oz.au (Graham Matthews)
Sun, 2 Aug 1992 23:37:36 GMT

          From comp.compilers

Related articles
[16 earlier articles]
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)
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)
[5 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: graham@maths.su.oz.au (Graham Matthews)
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Sun, 2 Aug 1992 23:37:36 GMT
References: 92-07-064 92-07-111
Keywords: translator, design

(Eliot Moss) writes:
>Suppose we have something like the following code:
> int *p, *q;
> int i;
> for (i = 0; i < 100; i++)
> p[i] = q[i];
>[C can promote p or q to a register and fail if the garbage collector
>moves the data that one of them points to]


I would suggest that you got your original C code wrong (remember this
discussion started on the them of using C as a low level IL). Your
tranlsator should have compiled the loop into


for( i = 0; i < 100; i++ )
object_access(p)[i] = object_access(q)[i];


where object_access() is a function returning a pointer to the storage
space for the array. The C compiler will not optimise this code (you may
have problems with global inter-procedural optimisations here but you can
usually turn them off).


You take a performance hit here but in the presence of GC surely you have
to take that hit no matter what IL you use?


Now if you are really sure that 'q' and 'p' above will not move (eg: you
only preform GC on allocation or deletion and you are sure that there will
be no collections inside the loop) you can code the loop as you suggest
above and the performance will be better. If you cannot guarantee this
condition then you cannot code the loop as above.


(Hans Boehm) writes:
>>>But the C standard does not guarantee that C compiler
>>>optimizations are safe in the presence of such a collector.
graham:
>[recording local pointer variables is slow]


Perhaps we are arging at cross purposes here. As far as I remember the
original post argued that C could not be used as an IL because of garbage
collection. I was attempting to argue that this is not so, that the
problems of garbage collection and moving pointers can be dealt with by
emitting "correct" C code. Granted you may have to do some work to get it
right.


Now the argument appears to have shifted to one of performance. I agree
that the peformance will be affected. My question is then whether the
performance loss is due to C or due to using GC. Surely in the presence of
GC one is always going to take a performance hit beacause the values of
pointers can change at any time?


graham
--
Graham Matthews
Pure Math, Uni.Sydney, Oz
graham@maths.su.oz.au
[Somebody suggested that it might be possible to define some extensions to
C that would make it easier to garbage collect. Any thoughts? -John]
--


Post a followup to this message

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