Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hcr.UUCP
Path: utzoo!hcr!mike
From: mike@hcr.UUCP (Mike Tilson)
Newsgroups: comp.lang.c
Subject: Re: Porting PCC
Message-ID: <2695@hcr.UUCP>
Date: Fri, 26-Jun-87 11:20:14 EDT
Article-I.D.: hcr.2695
Posted: Fri Jun 26 11:20:14 1987
Date-Received: Sat, 27-Jun-87 12:39:22 EDT
References: <2082@dg_rtp.UUCP> <5975@brl-smoke.ARPA>
Organization: HCR Corporation, Toronto
Lines: 55

John Mashey (mash@mips.UUCP), in response to my posting about the PCO
optimizer for UNIX compilers, comments:

>  ... A few notes in defense of from-scratch optimizers:
> a) A complete language system amortizes the overhead of having
> an optimizer by using common components for multiple frontends.
> In some domains, it IS important to support C, FORTRAN, PASCAL,
> PL/I, ADA, etc, etc, in a coherent way. [This is not to say that the
> PCO approach can't be used, just that you can think of developing
> technology easier if you know you're going to use it broadly.]
	This is true I think.  However, for this to really pay off
	you have to be fully committed to proper support of *all*
	of the languages.  The cost savings of using one "general"
	back end can be eaten up by the cost of designing and building
	PL/I, COBOL, and Ada front ends.  For this reason many
	organizations select compilers from vendors who specialize
	in each language (i.e. buy COBOL from COBOL experts, buy
	Ada from Ada experts, etc.)  Developers who have decided
	they would support "everything" have frequently produced
	mediocre implementations.

	In the case of MIPS, the compiler technology has been integral
	to the hardware design, and so this kind of effort may well
	be justified.
 
> b) At least some optimizers do compile the kernel [we do, so do others].
	I should add that as far as I can tell, MIPS has produced
	high quality compilers around, and my caution should not
	be applied to them.

> c) In our case, we gain about 15% [kernel] performance by adding the first
> level of global optimization ...
	I didn't mean to imply that optimization won't help, and it's
	always good to have more performance.  However, some more naive
	people see the usual "Puzzle sped up by xx%" benchmarks, and
	expect similar things from the kernel.

> d) I am curious to know if PCO is used to optimize device drivers.
> Even common subexpression elimination can surprise you if you don't
> support volatile.
	We can do three things:  1) By default all non-local storage
	is volatile -- this is needed if the C version doesn't have the
	"volatile" keyword.  2) A compiler flag can be set to assume
	that all storage is non-volatile.  (A customer can in fact
	make this the default behavior.)  3) The "volatile" keyword
	can be supported.  (In fact, we haven't yet done this because
	we haven't yet installed PCO in a compiler with "volatile",
	but as a result of (1) and (2) the necessary facilities
	exist.)

	A lot of thought and work was required to make sure this
	works correctly.  Prior to the invention of "volatile",
	we named such storage "evil" internally.

/Michael Tilson, HCR Corporation, {utzoo,ihnp4,...}!hcr!mike