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]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.