A branch too far

[peno at enea.UUCP]

>>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