Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!oliveb!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.arch
Subject: Re: Software Distribution
Message-ID: <28546@oliveb.olivetti.com>
Date: 6 Sep 88 17:26:10 GMT
References: <891@taux01.UUCP> <28200195@urbsdc>
Sender: news@oliveb.olivetti.com
Reply-To: chase@Ozona.UUCP (David Chase)
Organization: Olivetti Research Center, Menlo Park, CA
Lines: 45

In article <28200195@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes:
>
>>Yes, what we need is a high-level machine language that we can
>>translate our programs into and then is sufficiently general that we
>>can compile *that* efficiently into native machine code.
>>
>>How about C, the portable assembler?  :-) :-) :-)
>>
>>		    pardo@cs.washington.edu
>
>Treating this seriously - C isn't acceptable because the customer
>can take the C code and modify it relatively easily.
>

C loses technically, also.  It does not allow a code generator to
take the address of a label.  It does not allow a code generator to
reference the PC.  It provides no guarantees about register assignment
(not allocation; assignment).  These three non-features preclude the
use of some delightful tricks in the compilation of a language with
exceptions and exception handling (yes, I know about setjmp; it allows
a solution to our problem, but it is an inefficient solution).

C also loses as an intermediate language when the source language uses
nested procedures.  Again, you CAN do it, but it isn't very pretty.

C compilers also make pessimistic assumptions about aliasing, and
since there is no way for the front-end to communicate what it knows
to the C compiler.

The C "volatile" keyword is also overkill.  Efficient compilation of
exceptions is helped by more detailed descriptions of volatile change
and reference.  (For example, "volatile out" meaning that writes
cannot be optimized away, but reads can.)  This can be achieved,
painfully, by use of non-volatile temporaries to simulate caching of
values in registers.

Even if the front end does get very clever and performs register
allocation in C, it cannot know how many registers there are and it
cannot know how they are organized (do floats and ints share
registers?  How about floats and doubles?).

See, I've been figuring out how to use C as an intermediate language
in the last few months, and it really doesn't measure up.

David