ins_ajbh@jhunix.UUCP (01/28/87)
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"
donn@utah-gr.UUCP (02/06/87)
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@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...
peno@enea.UUCP (02/07/87)
>>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
guy@gorodish.UUCP (02/09/87)
>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.)