|Possible to write compiler to Java VM? (I volunteer to summarize) email@example.com (Peter Seibel) (1996-01-17)|
|Re: Possible to write compiler to Java VM? firstname.lastname@example.org (1996-02-09)|
|Aliasing in ISO C (was: Re: Possible to write compiler to Java VM?) email@example.com (1996-02-13)|
|Re: Aliasing in ISO C firstname.lastname@example.org (1996-02-14)|
|Re: Aliasing in ISO C email@example.com (1996-02-16)|
|From:||firstname.lastname@example.org (Ronald F. Guilmette)|
|Date:||13 Feb 1996 00:09:39 -0500|
|Organization:||Infinite Monkeys & Co.|
|Keywords:||C, design, GC|
Stavros Macrakis <email@example.com> wrote:
>Actually, there is a very direct bearing. There are several C
>features which make garbage collection difficult (although not
>impossible, as shown by the conservative collectors on the one hand
>and the interpretive C approach on the other), notably casts, untagged
>unions, and arrays without well-defined run-time lengths. There are
>also several features that make certain optimizations pretty much
>impossible, namely the possibility of almost arbitrary aliasing.
This is a fairly common misconception about C, IMHO.
The C standard is pretty clear in saying that in the following
function, it is permissible to avoid the second indirection and load
from *p1... assuming that you still have the value previously loaded
from *p1 in a register somewhere:
volatile int i;
volatile char ch1, ch2;
void foobar (char *p1, int *p2)
ch1 = *p1;
*p2 = i;
ch2 = *p1;
In other words, the C standard is pretty clear in saying that C only
supports aliasing of (i.e. multiple pointers to) ``compatible'' (which
in practice usually means ``identical'') types. In other cases, the C
standard makes few guarantees.
> Moreover, the low level of the language means that, although it is
> very easy to generate OK code for C, it is hard to optimize
> operations on higher-level structures, such as multidimensional
> arrays, and generate excellent code, especially on machines whose
> architecture is very different (e.g. distributed memory MIMD) from
> the flat byte address space, monoprocessor model implicit in C.
I would like to see the proof of this assertion. Once again, I believe
that the poster may be misreading the ISO C standard.
-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: firstname.lastname@example.org ----------- Purveyors of Compiler Test Suites -
Return to the
Search the comp.compilers archives again.