dvk@mi-cec.UUCP (Dan Klein) (02/20/84)
This is a continuation of my diatribe on "C doesn't optimize, it neatens". In this and other articles, I compare a true optimizing compiler (Bliss-32 running under VMS) to a code neatener (C running under BSD 4.1c). Any and all counterexamples are welcome. However, this is NOT a comparison of the languages. Both C and Bliss have their good and bad points. This is simply a comparison of the code they generate. As in all examples, the source code and uncensored assembly code is presented. In all examples, the C source and Bliss source are as nearly identical as language differences permit. I have not taken advantage of any "tricks" to get either language to perform better or worse than the other. The optimizer was enabled for both languages. -Dan Klein, Mellon Institute, Pittsburgh (412)578-3382 ============================================================================= In this example I declare three variables as register variables, clear them, and pass them to a routine. Well, C loses again. 1) Each variable gets the same value (namely 0), but Bliss saves space and time by having three CLRL's, while C does a CLRL and then MOVL's the first register into the other two. This is apparently a maneuver to save space when the right hand side is complex (i.e. calculate it once, and then put the known result into the other destinations). It loses here, since s CLRL is faster than a MOVL. 2) C allocates R9, R10, and R11, while Bliss uses R0, R1, and R2. This in itself is no big deal, but the C routine has to save three registers on routine entry, while Bliss only has to save 1 (namely R2, since R0 and R1 are the return registers). Compare the entry masks to see this. 3) The biggest lose of them all! C does three consecutive PUSHL's to pass the arguments to "alpha". Bliss knows that all the parameters are registers, and does 1 PUSHR. C could have done this too (i.e. the registers are declared in the right order to do this). While the register pushes take the same amount of time, the instruction interpretation is slower in C, and of course, the volume of code is greater. ----------------------------------------+------------------------------------- external routine alpha; | extern alpha(); | routine TEST : novalue = | test() begin | { register a,b,c; | register int a, b, c; | a = b = c = 0; | a = b = c = 0; alpha(.a, .b, .c); | alpha(a, b, c); end; | } | | .data .TITLE FOO | .text | LL0: .align 1 .EXTRN ALPHA | .globl _test | .set L13,0xe00 .PSECT $CODE$,NOWRT,2 | .data | .text TEST: .WORD ^M<R2> | _test: .word L13 CLRL R2 | clrl r9 CLRL R1 | movl r9,r10 CLRL R0 | movl r10,r11 PUSHR #^M<R0,R1,R2> | pushl r9 CALLS #3, W^ALPHA | pushl r10 RET | pushl r11 | calls $3,_alpha | ret
george@idis.UUCP (George Rosenberg) (02/21/84)
I do not understand the point of this. Your examples are not comparing the C language to the Bliss-32 (or Common Bliss) language. Your examples are comparing the results of two compilers. You are comparing the results of an optimizing compiler to the results of a simple compiler. Both compilers generate target code for the vax. The optimizing compiler is compiling programs written in Bliss-32. The simple compiler is compiling programs written in C. Your target machine is fixed, but both the compiler type and the language vary. Why not make the following comparisons each of which have only one variable? Compare an optimizing Bliss-32 compiler to an optimizing vax C compiler (such as the Amsterdam compiler). Compare a simple vax C compiler to an optimizing vax C compiler. Compare the Bliss-10 pdp-10 compiler to a Bliss-36 pdp-10 compiler. George Rosenberg idis!george
mark@umcp-cs.UUCP (02/27/84)
Ok. I already sent one mild flame objecting to the "mad neatener",
and trying to quietly argue that C doesn't do nearly so bad a job
as to be called a neatener. But now, claiming that bliss is
better because it uses 3 clrl's where C uses one and two movl's
is just plain wrong. On my vax, movl's are faster than clrl's.
(780 with no FPA.) Not much faster, but enough so that a little
loop doing a million of them does a little better than a little
loop doing a million clrl's, time and time again.
So bliss does it wrong.
--
Mark Weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs ARPA: mark@marylanddvk@mi-cec.UUCP (Dan Klein) (03/02/84)
"The mad neatener". Hmm, I think I like that one. Okay, I really should have called it an "improver", and if indeed your VAX executes MOVL's faster than CLRL's, then *both* the implementation of Bliss and of C do it right. It is simply the case that Bliss wins for space, and C wins for speed. (Hey, I'm not perfect, I just act like I think I am...) -Dan Klein, Mellon Institute, Pittsburgh (412) 578-3382
wls@astrovax.UUCP (03/05/84)
> I do not understand the point of this. > Your examples are not comparing the C language > to the Bliss-32 (or Common Bliss) language. Maybe I'm missing something but I thought the whole point was not comparing the two languages C vs. BLISS but to show that the "standard" BSD / USG C compiler optimizes inadequately. Personnally I can understand why the Fortran compiler is an embarrasement, considering the attitude in this community toward Fortran. However, I cannot understand why Unix does not come with a super-optimizing C compiler, as any increase in the speed of the code produced will speed up all of Unix. Surely by now better could be done. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wls
alan@allegra.UUCP (Alan S. Driscoll) (03/05/84)
> Maybe I'm missing something but I thought the whole point was not comparing > the two languages C vs. BLISS but to show that the "standard" BSD / USG C > compiler optimizes inadequately. > Personnally I can understand why the Fortran compiler is an embarrasement, > considering the attitude in this community toward Fortran. However, I > cannot understand why Unix does not come with a super-optimizing C compiler, > as any increase in the speed of the code produced will speed up all of Unix. > Surely by now better could be done. > -- > Bill Sebok Princeton University, Astrophysics > {allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wls Yes, but have you ever heard of a Portable Bliss Compiler? The effort has simply been in different directions. -- Alan S. Driscoll AT&T Bell Laboratories