🚀 go-pugleaf

In article <3181@husc6.UUCP> singer@endor.UUCP (Richard Siegel) writes:
|In article <4285@sdcsvax.UCSD.EDU> borton@net1.UUCP (Chris Borton) writes:
|>Thank you Alan for the description of [in]efficient 68000 code generation.
|>
|>I am curious to hear 'expert' opinions on the code generated by LightspeedC,
|
|	Me too. :-)

Ask, and ye shall receive...

The code generated by a compiler is generally detirmined by two phases, the
optmizer and the code generator.  The former generally does machine independent
optimizations such as common subexpression elimination (where if an expression
is performed more then once, the compiler modfies the code to execute the
expression once and save the result in a temporary), code hoisting (where
for each loop, any code that generates the same value every time through the
loop is 'hoisted' out of the loop and done once), etc.  The code generator
is what takes the internal machine independent representation and converts
it to the assembly or machine language of the target machine.

For LightspeedC, the code generator is as good as any I've seen.  I've never
seen it generate a brach-to-branch, which suggests Micheal Kahl did not do
a straight-forward code generator but spent a lot of time on it.  About the
only thing that it needs is a peep-hole optimizer for some cases that
occur between statements such as:

     move.w	d0, d7
     move.w	d7, d0		; This instruction is not needed
     ...

is generated for the expression

    register int rc;

    rc = function()
    if (rc == 0x80)

(Note, I don't have the code in front of me so this example may not generate
the code I'm thinking of, but the problem exists in this area).

The thing LightspeedC lacks is an optimizer.  The reason is that optmizers
are large and (usually) slow.  So for testing, which is probably 99% of
the compiles done, a optimizer is not needed since it doesn't matter how
fast a program doesn't work :-).   The lack of an optimizer in LightspeedC
is why MPW will generate smaller code then LightspeedC.  The code will usually
be faster but MPW loses a lot here by using 32 bit ints vs LightspeedC's
16 bit ints.

|
|* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer    *


Jerry Whitnell				Lizzi Borden took an axe
Communication Solutions, Inc.		And plunged it deep into the VAX;
					Don't you envy people who
					Do all the things You want to do?