C "optimization" (6 of 8)

[Guy Harris]

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