AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (05/23/88)
>Date: Mon, 16 May 88 15:09:09 GMT >Reply-To: Info-Apple@BRL.ARPA >From: "Paul R. Wenker" > <pacbell!att!chinet!mcdchg!clyde!meccts!meccsd!prw > %ames.arc.nasa.gov@BRL.ARPA> >Subject: Re: APW C and Mac Cross Development > >From my experiences, APW C is sort of the AppleSoft for the GS. The >code isn't very fast or very small, but it's good for quick and dirty >programs. [Interesting...if APW C is the "Applesoft for the GS", then what is Applesoft? It's still in the GS! :-) ] Anyway, I will buy that analogy as long as you don't take it too far. APW C's usefulness certainly not limited to quick and dirty programs. Unlike Applesoft, it provides actual high-level data structures, named functions, local variables, etc.--The lack of stuff like that is what makes Applesoft hard to use for big projects. >The benchmarks we did showed APW C programs to be 3-6 times larger >than equivalent assembly programs. Also, they were 1/5 to 1/20 the >speed (the more toolbox calls, the better the speed). There is an >interesting article in a recent (April?) issue of Call -A.P.P.L.E. >It does some benchmarks of assembly, Pascal, and C. The benchmark >that sticks out in my mind is one where the assembly program takes 1.5 >hours to complete, while the Pascal program takes ~5 hours and the C >program takes 18 hours. The 3-6 times larger statistic sounds about right to me. At the risk of being classified as one of those programmers who "gets careless with RAM usage on the IIgs," let me say that it is often more important to write code quickly than to use the minimum amount of RAM. If execution speed is the issue, critical parts can be written in assembly while leaving most of the code in C. Case in point: On Friday night I started, completely from scratch, a ProDOS 16 version of my command shell (Davex-16). I'm writing it mainly in C. I have spent about 32 hours on it so far, and I have wasted some time being disorganized and re-writing things when I didn't like the way they were working out. Even so, the thing is already a minimally usable command shell--the source is over 1000 lines of C and a couple hundred of assembler (prolog to replace the START.ROOT code, plus code intercept ProDOS calls intended for the shell). It's nowhere near finished, but if I were doing this in straight assembly I would have only a fraction of what I have now (and I consider myself a reasonably fast assembly language programmer). >-Paul R. Wenker >-MECC, Technical Services --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2