Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!enea!peno
From: peno@enea.UUCP
Newsgroups: comp.lang.c
Subject: Re: A branch too far
Message-ID: <1677@enea.UUCP>
Date: Fri, 6-Feb-87 19:04:08 EST
Article-I.D.: enea.1677
Posted: Fri Feb  6 19:04:08 1987
Date-Received: Mon, 9-Feb-87 02:00:56 EST
References: <4340@jhunix.UUCP> <1909@utah-gr.UUCP>
Reply-To: peno@enea.UUCP (Pekka Nousiainen)
Organization: ENEA DATA Svenska AB, Sweden
Lines: 30
Keywords: PCC, ccom

>>Actually you can get the "branch too far" problem from big 
>>FOR loops as well. I feel it just another reflection of the 
>>sad state of the PCC based VAX C compiler.

>Do I really have to explain this?  The PCC does the job it was designed
>to do -- it's simple, mostly reliable and easy to port to many
>architectures.

PCC is perhaps best thought of as a fancy macro processor.  It
doesn't try to "understand" the C code nor do optimizations other
than the one required by the semantics of C: constant collapsing.

PCC operates on the WYSIWYG principle.  For example, the input

	f() { register x, y; ...

predictably allocates two registers, even if the uses of x and y in
the function body do not overlap.  Similarly, if you use a temporary
variable to increase the clarity of the code, the variable will be
allocated on the stack even when it is not necessary.

The optimizer /lib/c2 which operates on the assembler output cannot
undo these choices.

I tend to agree with the 2nd poster.  Also, parts of the kernel depend
on the predictability of PCC (boot parameters are passed in a register).
When optimization really does matter one should use a commercial C
compiler such as Tartan cc.
--
..!mcvax!enea!peno