Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!endor!singer
From: singer@endor.harvard.edu (THINK Technologies)
Newsgroups: comp.sys.mac
Subject: Re: Compiler efficiency
Message-ID: <3282@husc6.UUCP>
Date: Sun, 22-Nov-87 16:07:43 EST
Article-I.D.: husc6.3282
Posted: Sun Nov 22 16:07:43 1987
Date-Received: Tue, 24-Nov-87 06:39:17 EST
References: <3987@watdragon.waterloo.edu> <17000058@clio>
Sender: news@husc6.UUCP
Reply-To: singer@endor.UUCP (THINK Technologies)
Organization: THINK Technologies, Bedford, MA
Lines: 36

In article <17000058@clio> hannon@clio.las.uiuc.edu writes:
>	After disassembling some Lightspeed Pascal generated code I can
>say without a shadow of a doubt that it is some of the WORST code (if not
>the worst) I have ever seen.  Now, I have to admit, that one of the reasons
>for this is that LSP is a ONE PASS COMPILER which accounts for its speed, but
>that should not effect the code as much as it does...  It is not uncommon to
>find a sequence of NOP's in  the code, let alone places where three
>instructions are used instead of one.

	Lightspeed Pascal's compiler is a one-pass compiler, which means
that no optimization is done; this means that in many cases you'll see
instances of three instructions being used where one would serve.
The NOPs in the code used only for procedures that don't need to save
the machine registers... Granted that this is not good style, but it
doesn't affect the overall efficiency of the code.

>	I've even had one instance where the code generation was soo poor
>that it caused my INIT to crash because it somehow modified the PC!!!

	If you can show me a reproducible example where Lightspeed Pascal
generated bad code, I would be most happy to see it. The few instances where
garbage code gets generated are well documented, and this is not one of them.

>+  Leonard Rosenthol                |  USnail:   205 E. Healey  #33        +

		--Rich




**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies).

* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer    *
* Customer Support  | singer@endor.harvard.edu			    *
* Symantec, THINK Technologies Division.  (No snappy quote)         *