Path: utzoo!utgpu!watmath!iuvax!rutgers!apple!dlyons
From: dlyons@Apple.COM (David Lyons)
Newsgroups: comp.sys.apple
Subject: Re: Languages for an Apple //e - //c (was P-Code Systems)
Message-ID: <32217@apple.Apple.COM>
Date: 2 Jun 89 22:37:38 GMT
References: <1373@tellab5.tellabs.CHI.IL.US>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 28

In article <1373@tellab5.tellabs.CHI.IL.US> toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) writes:
>[...]
>I agree, Mr. Lyons, that if you are refering to an implementation on a //gs,
>a dreaded IBM, or any of a number of other computers where a processor that
>supports large stack frames is used, that a P-Code system is dreadfully
>innefficient compared to Native Code Compiles.

I don't recall ever arguing that P-code is dreadfully inefficient compared
to native code.  Actually, I thought my main point was that p-code efficiency
could be pretty decent, and that the code could be a lot more compact.

>[...]                    A guy I work with bought Aztec 'C' anf compiled
>a program with a single procedure that did 'printf ( "Hi" );', this one
>stament program compiled to approximately a 4K byte program - no disk I/O
>or any other functions).

Not too surprising--printf() is a powerful function, and the compiler didn't
know that his program wasn't going to use that power.  Using puts instead
of printf should reduce the size considerably.

 --Dave Lyons, Apple Computer, Inc.          |   DAL Systems
   AppleLink--Apple Edition: DAVE.LYONS      |   P.O. Box 875
   AppleLink--Personal Edition: Dave Lyons   |   Cupertino, CA 95015-0875
   GEnie: D.LYONS2 or DAVE.LYONS         CompuServe: 72177,3233
   Internet/BITNET:  dlyons@apple.com    UUCP:  ...!ames!apple!dlyons

   My opinions are my own, not Apple's.