Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.lang.c Subject: Re: C "optimization" (6 of 8) Message-ID: <1754@rlgvax.UUCP> Date: Thu, 23-Feb-84 00:51:27 EST Article-I.D.: rlgvax.1754 Posted: Thu Feb 23 00:51:27 1984 Date-Received: Fri, 24-Feb-84 00:01:03 EST References: <211@mi-cec.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 42 A few comments: 1) MOVO is not even guaranteed to be available on an 11/750 or 11/780. It's "real" name is MOVH (moves an H-floating value), and is only provided with the G/H-floating option. (I agree, though, catching the two "pushl"s and converting them to a "movq" would be good.) 2) Dan is right in that the extra code to eliminate redundant ".data" and ".text" operations would probably be extremely minor (checking "pcc/code.c", there are only a few places that emit them, and wrapping a test of a state variable and a set/clear of that state variable around it would be all it would seem to take), but I didn't check it in detail to see if there are any hidden "gotcha"s. Morris is right in that it probably doesn't make enough of a difference to worry about; yes, penny candy is far cheaper than 10 cent candy but unless your allowance is 10 cents/week. The extra I/O overhead is equivalent to (7*number of extraneous pseudo-ops)/(buffer size) which means that it takes about 73 extraneous pseudo-ops to require one extra "write" or "read" system call; percentagewise, this is probably a drop in the bucket. The only other overhead is that of the calls to "printf" which write the extra pseudo-ops (negligible, considering all the other things compilers do) and the code in the assembler to process them (probably the most significant overhead of them all, and I suspect it is still small, percentagewise). Trimming the extra .data/.text isn't the place to put your effort if you're trying to improve the performance of your machine or your compiler. 3) Even though this is a comparison of implementations, not languages, the point is well taken that perhaps better language implementations under UNIX should be considered. There is resistance to UNIX among people doing scientific computation, because its FORTRAN 77 implementation produces code which produces correct answers, but doesn't produce them in anything near the most CPU-efficient manner (and, believe me, CPU efficiency *counts* in that environment!). I suspect the relative lack of development of the code quality of UNIX compilers is due to the greater interest in portability than in code quality of the developers and the code quality of those compilers being judged adequate by their users. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy