Aliasing in ISO C (was: Re: Possible to write compiler to Java VM?) (Ronald F. Guilmette)
13 Feb 1996 00:09:39 -0500

          From comp.compilers

Related articles
Possible to write compiler to Java VM? (I volunteer to summarize) (Peter Seibel) (1996-01-17)
Re: Possible to write compiler to Java VM? (1996-02-09)
Aliasing in ISO C (was: Re: Possible to write compiler to Java VM?) (1996-02-13)
Re: Aliasing in ISO C (1996-02-14)
Re: Aliasing in ISO C (1996-02-16)
| List of all articles for this month |

From: (Ronald F. Guilmette)
Newsgroups: comp.compilers
Date: 13 Feb 1996 00:09:39 -0500
Organization: Infinite Monkeys & Co.
References: 96-01-037 96-02-082
Keywords: C, design, GC

Stavros Macrakis <> 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: ----------- Purveyors of Compiler Test Suites -

Post a followup to this message

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