Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c
Subject: Re: A branch too far
Message-ID: <12909@sun.uucp>
Date: Sun, 8-Feb-87 19:05:02 EST
Article-I.D.: sun.12909
Posted: Sun Feb  8 19:05:02 1987
Date-Received: Mon, 9-Feb-87 04:51:55 EST
References: <4340@jhunix.UUCP> <1909@utah-gr.UUCP> <1677@enea.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 29
Keywords: PCC, ccom

>PCC operates on the WYSIWYG principle.

I wouldn't go that far.  The fact that it assigns registers in a
particular order is NOT a deliberate feature, and implementors are
completely free to change its behavior.

>Also, parts of the kernel depend on the predictability of PCC (boot
>parameters are passed in a register).

Parts of *some* kernels, please!  *Our* kernel passes them as
strings.

The fact that some parts of the kernel depend on this is irrelevant,
and cannot be used to require that compilers do only simple-minded
register assignment.  When this sort of stuff is necessary, it
*should* be done via some sort of pragma.  ANSI C has a #pragma
control line for just this sort of thing.  You could modify your
compiler (even if you don't implement all of ANSI C) to permit things
like

	#pragma	use_register	variable_in_r0	r0

>When optimization really does matter one should use a commercial C
>compiler such as Tartan cc.

Or add an optimizer to a PCC-based compiler, as has been done at various
places.  (The 4.[23]BSD FORTRAN optimizer, and Sun's FORTRAN
optimizer, slide in between the first pass of "f77" and the PCC-based
FORTRAN code generator.)