Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site decwrl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decwrl!vantreeck@logic.DEC
From: vantreeck@logic.DEC
Newsgroups: net.micro.mac
Subject: slow C compilers
Message-ID: <417@decwrl.UUCP>
Date: Fri, 13-Sep-85 12:02:26 EDT
Article-I.D.: decwrl.417
Posted: Fri Sep 13 12:02:26 1985
Date-Received: Sat, 14-Sep-85 08:13:44 EDT
Sender: daemon@decwrl.UUCP
Organization: Digital Equipment Corporation
Lines: 93


 
>I used Hippo C and found it to be s-l-o-w.  For compilation, Level 2 on a RAM
>disk was no faster than some other compilers on floppies.

	I would gladly pay 2 to 3 times the current prices for a v-e-r-y
s-l-o-w compiler on the Mac that makes several passes to generate optimized
code. I'm looking for a compiler that does more than constant folding and
compile time evaluation of constants. 

        If anyone knows of a Mac C or Pascal compiler that performs at least
most of the following optimizations, I and others would like to know about it.

	o	Compile-time evaluation of constant expressions

	o	Rearranging unary minus and not ("!") operations to eliminate
		unary negation/complement operations

	o	Partial compile-time evaluation of logical expressions

	o	Elimination of constant common subexpressions

	o	Elimination of unreachable code

	o	Code hoisting from structured statements

	o	Removal of invariant computations from loops

	o	Inline code expansion of small predeclared functions

	o	Inline expansion of static (local), user defined functions

	o	Global assignment of variables to registers base on frequency
		of reference

	o	Reordering the evaluation of expressions to minimize the number
		of temporary values needed (may not garuntee left to right
		evaluation)

	o	peephole optimzation of instruction sequences - the following
		are three examples of code generated by a popular C compiler,
		I'll use equivalent C statements for the generated code to
		make the example clearer.

		1)	char a; ... if (a & 0x80)  /* test bit 7 of a */

			generates:

				{
					register char t = a;
					t &= 0xFF; /* clear upper 3 bytes */
					t &= 0x80; /* set bit 7 */
				}
				if (t) ...

			correct code should be:

				{
					register char t = a;
					t &= 0x80; /* set bit 7 */
				}
				if (t) ...

				obviously "t &= 0xFF" is entirely unnecessary
				because anding with 0x80 will clear the upper
				bytes anyway - doesn't have to be done by
				peephole optimizer but it can be done there.


		2)	char a; ... if (a & 0x80)  /* test bit 7 of a */

			The compiler fails to recognize the 0x80 is a number
			that is 2 raised to an integer value. If it did
			recognize that fact it,	would be able to use a test
			bit instruction instead of anding and then testing
			the result. This can be generalized to the setting
			and clearing of bits as well - this doesn't have to
			to be done by the peephole optimizer but it can be.

		3)	struct foo { int a, b, c; }... 
			foo.a = z;
			foo.b = 1;
			foo.c = alpha;

			The compiler will load a pointer to foo into a register,
			assign the value z to a, reload a pointer to foo into
			the same register as before, assign the value 1 to b,
			reload, AGAIN, a pointer to foo into the same register,
			assign alpha to foo.c. If the compiler were of any
			decent quality it would only load a pointer to foo
			ONCE!!!

-George