Re: Pros and cons of high-level intermediate languages

(Santosh Pande) writes:
>I am interested in knowing the pros and cons of using an
>intermediate language (IL) in general. In particular I find 'C' has
>been used extensively as the IL in ..
>..
> (1) I am looking for examples in which using C as IL will lead to
>inefficiencies,


(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. It
>appears that the only way not to lose appreciably in performance
>(and this is a bit controversial) is to use a conservative garbage
>collector. But the C standard does not guarantee that C compiler
>optimizations are safe in the presence of such a collector.


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.


For example say you have something of the form


access_to_memory = function_that_causes_garbage_collection


Now if you compile this directly into C you are in trouble as C
does not define the order of evaluation of the lhs with respect
to the rhs (if the rhs is done first you are ok otherwise you
have problems).


However this problem can be handled by compiling into C code of
the form,


temp = function_that_causes_garbage_collection;
access_to_memory = temp;


This construction forces the order of evaluation you require. If an
optimizer "optimises" this code back to the original form then your
optimiser is incorrect.


So as far as I can see C is not unsafe in the presence of garbage
collection as long as you are careful in your code emission. Your code
will not be as fast as native C but then as far as I can see there is no
way to avoid forcing the order of evaluation in any general solution to
the above probelm so C will do no worse than any other system.


Perhaps you have some specific problems in mind ...


graham
--
Graham Matthews
Pure Math, Uni.Sydney, Oz
graham@maths.su.oz.au
[The usual problem is to identify all possible live data, notably that
pointed to by variables on the stack and in registers. -John]
--

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