A branch too far

[donn at utah-gr.UUCP]

Sigh:

	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. It often generates
	unexpected and/or non-optimal assembly code. According to the
	Berkely folks at USENIX they have made no improvements in the
	compiler aside from fixing the signed/unsigned bugs. Has any 
	outside work been done on fixing this turkey up.

	jim

	"Work is the Curse of the Drinking Class"

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.  It adequately supports the work which the Berkeley CSRG
does, and they don't have the manpower to spare for work on a
replacement.  (Almost all the compiler fixes -- quite substantial
amounts of fixes -- come from people outside Berkeley.  This outside
effort has been going on for years, apparently utterly unnoticed in
some quarters...) If you want a compiler that does more than what the
PCC does, you can buy one: there are perfectly good commercial quality
C compilers which will out-optimize the PCC, and which have official
vendor support.  If you aren't satisfied with commercial compilers and
you have time on your hands, you can write your own, like Richard
Stallman did.  I have little sympathy for people who complain about
free software, and less for those who won't contribute solutions for
their complaints.

This is what I missed by passing up Usenix,

Donn Seeley    University of Utah CS Dept    donn at cs.utah.edu
40 46' 6"N 111 50' 34"W    (801) 581-5668    utah-cs!donn

PS -- No, I don't really want to get into an argument with RMS about
how free the 4.3 BSD PCC is...