vantreeck@curie.dec.com (12/16/87)
>>Can anyone tell me the relative merits/demerits of Aztec C (or some other >>inexpensive development environment) vs. LightSpeed on the Mac ][. >> >>LightSpeed is what everyone seems to recommend, but Aztec says it has a >>symbolic debugger (any good? I'm used to codeview on a PC and dbx on UNIX) >>make (does LSC have this?) and unlimited data size (this is important as >>I hope to port a prolog compiler from UNIX eventually, does LSC let you >>have huge memory spaces? - I want to have as much of my 5 megs for heap >>as possible) Funny you should mention "PROLOG" and large data model. I wrote a PROLOG compiler for the Mac using a mixture of C and assembler. And I used the large data model. I used Manx's Aztec C compiler and assembler. It is THE ONLY compiler available on the Mac that supports both the large code and large data models. Alas, I can't share my PROLOG with anyone because my employer says Apple is competitor and any software on a competitors hardware makes it more viable competition, i.e., conflict of interest (translates to don't bother asking for it). > I've heard that the Aztec symbolic debugger doesn't exist, but >I've never seen it, so I can't be more definite than that. Aztec has had a VERY NICE symbolic debugger, db, for a long time. Aztec C provides compiler and link options to also generate symbol tables that can be used by other debuggers, e.g., MacsBug and Tmon. Manx is developing a source line debugger, sdb. > LightspeedC has *more* than make. It's got full automatic project >management, which means that you'll never have to write a makefile. LightSpeed C also has *less* than Aztec's make if your complete system contains modules written in other languages. If you wish to also rebuild C, Pascal, and assembly language modules into a program, Aztec's make is the preferred tool. Last time I checked, LightSpeed C required all source files in project to be in one directory. Aztec's make does not have that limitation, e.g., I have sources to built-in predictes in one director, unification engine in another directory, and database routines in yet another, etc.. For larger development projects you will probably have sources in multiple directories and have complicated dependencies that an automated make, like LightSpeed's, can't handle. In that case, you will no choice but to use a standard make facility. Note, that if you're porting a PROLOG compiler based on the WAM (Warren's Abstract Machine), you will probably use assembly language for the engine so that you can specify global register allocation (means at least a doubling of performance for PROLOG). And you would also prefer to directly access data without having to index off the A5 register (using that register instead for a globally allocated PROLOG "A/X" register), i.e., you'll probably want to use Aztec C's large data model and a mult-language support of Aztec's make. [Contrary to what some might think, I found programs compiled for the large data model generated slightly smaller object files and ran slightly faster.] With LightSpeed C you have to leave their environment to build non-C modules. You don't have to leave the Aztec C shell when building non-C modules. LightSpeed C makes no attempt to integrate non-Think products into it's environment. Manx makes a good effort at having an open interface that lets you integrate other tools into the environment. As an example, clicking on the "Edit" item in the menu brings up my QUED editor instead of the default Aztec editor, z (which is like vi). If you're more interested in quick prototyping than careful up-front design (and you're only using C), then LightSpeed C will be particularly appealing because of the quick turn-around time. Aztec C and LightSpeed C are in the same ball park with respect compilation and link times, code size, and run-time speed. Neither is too hot a code optimization, e.g., neither does common subexpression elimantion, loop jamming, dead code elimination, etc.. I hear Green Hill's C compiler that works with Apple's MPW does an excellent job of optimization -- but does not support the large data nor large code models. **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (Digital Equipment Corp.) George Van Treeck Digital Equipment Corporation (The home of industrial-strength software tools.)
singer@endor.harvard.edu (THINK Technologies) (12/16/87)
Rather than argue the merits of one versus the other (noticed that I started this, now I get to pay) I will simply respond to specific technical points... In article <8712152132.AA10832@decwrl.dec.com> vantreeck@curie.dec.com writes: >Aztec has had a VERY NICE symbolic debugger, db, for a long time. Aztec C >provides compiler and link options to also generate symbol tables that can be >used by other debuggers, e.g., MacsBug and Tmon. Manx is developing a source >line debugger, sdb. My apologies for that; I did mean to say "source level" debugger. Using TMON in conjunction with LightspeedC it is also possible to get symbolic debugging that resembles Aztec's. >Last time I checked, LightSpeed C required all source files in project to be in >one directory. Aztec's make does not have that limitation, e.g., I have sources When was the last time you checked? Every version since 2.01 has complete support for HFS, and that's largely automatic, so you don't need to specify pathnames for #include files, and you can add source and library files from *any* directory - or even another disk. >and database routines in yet another, etc. For larger development projects you >will probably have sources in multiple directories and have complicated >dependencies that an automated make, like LightSpeed's, can't handle. In that >case, you will no choice but to use a standard make facility. LightspeedC was written using itself. The sources are in multiple directories. It consists of over a hundred source files, plus various libraries and #includes. >With LightSpeed C you have to leave their environment to build non-C modules. >You don't have to leave the Aztec C shell when building non-C modules. >LightSpeed C makes no attempt to integrate non-Think products into it's >environment. Manx makes a good effort at having an open interface that lets you >integrate other tools into the environment. As an example, clicking on the >"Edit" item in the menu brings up my QUED editor instead of the default Aztec >editor, z (which is like vi). Granted that all of the above is true. But the integrated decision was made with speed in mind. How long does it take you to go from QUED to the compiler? On a hard disk, maybe not long. But in LightspeedC, the compiler is *right there*. >If you're more interested in quick prototyping than careful up-front >design (and you're only using C), then LightSpeed C will be particularly >appealing because of the quick turn-around time. LightspeedC is certainly appealing because of its quick turnaround, but I disagree with the assertion that it's only good for prototyping. After all some very popluar Macintosh programs (Aldus PageMaker, Adobe Illustrator, Quark XPress, Red Ryder, StuffIt, LightspeedC itself, and others) were written using LightspeedC. I would hesitate to call these "Quick Prototypes". >Aztec C and LightSpeed C are in the same ball park with respect compilation and >link times, code size, and run-time speed. Neither is too hot a code >optimization, e.g., neither does common subexpression elimantion, loop jamming, >dead code elimination, etc.. I hear Green Hill's C compiler that works with >Apple's MPW does an excellent job of optimization -- but does not support the >large data nor large code models. I hear the same. > >George Van Treeck >Digital Equipment Corporation (The home of industrial-strength software tools. --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) *
cramer%clem@Sun.COM (Sam Cramer) (12/17/87)
A couple more advantages of LSC over Manx: it is *very* inexpensive, it
is discounted, and Think doesn't charge you an arm and a leg for updates.
In fact, they are usually free. Further, the Think folks are clearly
very concerned with supporting their customers (as evidenced by their
presence in this forum).
Hats off to Think for producing a cheap, high-quality product. I just hope
that they don't catch Borland disease and decide to increase their prices...
Sam Cramer {cbosgd,decwrl,hplabs,seismo,ucbvax}!sun!cramer cramer@sun.comanson@elrond.CalComp.COM (Ed Anson) (12/17/87)
>In article <8712152132.AA10832@decwrl.dec.com> vantreeck@curie.dec.com writes: >>With LightSpeed C you have to leave their environment to build non-C modules. When using LSC 2.13 with MultiFinder, this is not an issue. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
jwhitnel@csi.UUCP (Jerry Whitnell) (12/18/87)
In article <8712152132.AA10832@decwrl.dec.com> vantreeck@curie.dec.com writes: >>>Can anyone tell me the relative merits/demerits of Aztec C (or some other >>>inexpensive development environment) vs. LightSpeed on the Mac ][. > >Funny you should mention "PROLOG" and large data model. I wrote a PROLOG >compiler for the Mac using a mixture of C and assembler. And I used the large >data model. I used Manx's Aztec C compiler and assembler. It is THE ONLY >compiler available on the Mac that supports both the large code and large data >models. Alas, I can't share my PROLOG with anyone because my employer says >Apple is competitor and any software on a competitors hardware makes it more >viable competition, i.e., conflict of interest (translates to don't bother >asking for it). I'm not sure what you mean by large code/data (sounds like x86 compilers). If you mean >32K globals or >32K code in a single segment, then you are correct about LightspeedC not handling large code/data. It will handle correctly >32K objects on the heap, however. > >> I've heard that the Aztec symbolic debugger doesn't exist, but >>I've never seen it, so I can't be more definite than that. > >Aztec has had a VERY NICE symbolic debugger, db, for a long time. Aztec C >provides compiler and link options to also generate symbol tables that can be >used by other debuggers, e.g., MacsBug and Tmon. Manx is developing a source >line debugger, sdb. LightspeedC is also compatible with MacsBug (comes with LightSpeedC) or TMON. Manx has (unfortunatly) been developing their source level debugger for a long time (> 2 years, I think), but hasn't shipped anything yet. THINK is also working on one for LightspeedC, rumored first quarter 88. > >> LightspeedC has *more* than make. It's got full automatic project >>management, which means that you'll never have to write a makefile. > >LightSpeed C also has *less* than Aztec's make if your complete system contains >modules written in other languages. If you wish to also rebuild C, Pascal, and >assembly language modules into a program, Aztec's make is the preferred tool. True, although LightspeedC has inline assembly language. Also promised RSN is a way to load libraries from Lightspeed Pascal into LightspeedC projects. Finally, LightspeedC's integrated project gives a tags like facility where selecting a global identifier or function name will autmatically open up the file containing the declaration of the identifier/function. Very handy. Finally, you don't have to write/debug your make files like you have to with a make utility, you just add the .c files to the project and LightspeedC automaticaly figures out the depenedicies. >Last time I checked, LightSpeed C required all source files in project to be in >one directory. Aztec's make does not have that limitation, [example deleted]. You are refering to Version 1.03 (pre-HFS). The current version (2.13) supports HFS completly so you can have the sources anywhere you want. It also has automatic searchs for .h files so you don't have to tell it where they are. >Note, that if you're porting a PROLOG compiler based on the WAM (Warren's >Abstract Machine), you will probably use assembly language for the engine so >that you can specify global register allocation (means at least a doubling of >performance for PROLOG). And you would also prefer to directly access data >without having to index off the A5 register (using that register instead for a >globally allocated PROLOG "A/X" register), i.e., you'll probably want to use >Aztec C's large data model and a mult-language support of Aztec's make. LightspeedC supports inline assembler, which makes it much easier to maintain appilcation specific assembly code (one set of defines, not two). Also supports large data on the heap (where it's most likely to be). > >[Contrary to what some might think, I found programs compiled for the large >data model generated slightly smaller object files and ran slightly faster.] > >With LightSpeed C you have to leave their environment to build non-C modules. >You don't have to leave the Aztec C shell when building non-C modules. >LightSpeed C makes no attempt to integrate non-Think products into it's >environment. Manx makes a good effort at having an open interface that lets you >integrate other tools into the environment. As an example, clicking on the >"Edit" item in the menu brings up my QUED editor instead of the default Aztec >editor, z (which is like vi). True, although with MultiFinder, this is less of a problem. One nice feature of LightspeedC is that if you launch the program under MultiFinder, it will not close LightspeedC, but launch the application in a sperate partition. Which means you can look at the source code while running your application. Also instant return to the LightspeedC enviroment when the application terminates (no load time). Requires at least 2 mb (Thanks Apple, under switcher the whole thing worked fine in 1 mb). > >If you're more interested in quick prototyping than careful up-front >design (and you're only using C), then LightSpeed C will be particularly >appealing because of the quick turn-around time. I find programming the Mac requires both up-front design and prototying. You usualy have to play with the user-interface to get it to feel right, but the application-specific code can be designed. But I don't like waiting for the compiler in either case, or more important during unit and system test. The less time I spend waiting for the compiler, the quicker my application gets done. > >Aztec C and LightSpeed C are in the same ball park with respect compilation and >link times, code size, and run-time speed. Neither is too hot a code >optimization, e.g., neither does common subexpression elimantion, loop jamming, >dead code elimination, etc.. I hear Green Hill's C compiler that works with >Apple's MPW does an excellent job of optimization -- but does not support the >large data nor large code models. True. Although MPW uses 32 bit ints, which negates a lot of the optimization since both Aztec and LightspeedC use 16 bit ints. Declare all you ints as short and you'll get better performance from MPW. Another point in favor of LightspeedC is support is the best I've seen from any company. They offer on-line support both here (Hi, Rich), on Delphi and on Compuserve. Probably other places as well. Updates appear on a regular basis and have been free. Minor updates are distributed via the networks, major updates via US Snail. The author (Micheal Kahl) also posts to Compuserve on an irregualar basis. I've programmed on IBM PCs (Microsoft C bleech!), UNIX and the Mac (Megamax and LightspeedC) and of all the choices, I still think LightspeedC is the best enviroment for single programmer development using C on any machine (that I've used). > >George Van Treeck (Sorry about the quote George, it's not a flame at you :-)). 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?
raylau@dasys1.UUCP (Raymond Lau) (12/18/87)
Personally, I am an Aztec to Lightspeed convert. I don't regret the decision.
I find that the speed and performance of LS more than outweighs its disadvantag
es.
It is a LOT easier to quit, make a change and press cmd-R (run) esp under MF,
where transferring is instant... than quitting the application, running qued/m
...running cc...running ln... under Aztec. I've found that the turnaround
time in making little changes is the majority of the development time.
Although Aztec has it too, LSC's inline assembly feature is nice. (As a matter
of fact, I didn't really use lsc for anything before it) Some things are just
better done in .asm.
On the negative side, I miss an intergrated debugger, although I don't make
use of them much anyway. I hate the 32k data limit. With a hash table in
the order of 200+k, the 32k limit seems to have been exceeded easily. I
am not too thrilled about the generated code size, although Aztec's is only
marginally better. And a host of other little things.
One last thing...I don't know}i about 020/881 support in LSC. I guess that
that might be important soon (read that as "as soon as I get a machine w/such").
Overall, my vote is in for LSC. And that's after shelling out the $ for Aztec
initially.
--
Raymond Lau GEnie: RayLau
100-04 70 Ave. CIS: 76174,2617
Forest Hills, NY 11375-5133 Delphi: RaymondLau
United States of America MacNET: RayLau
uucp: raylau@dasys1.UUCP (..{phri,cucard,bc-cis,mstan}!dasys1!raylau})
s
much use of debuggers anyway. I hate the olson@endor.harvard.edu (Eric K. Olson) (12/18/87)
In a recent article Sam Cramer writes: >A couple more advantages of LSC over Manx: ... I use LSC 2.13 (which is fully Mac II capable, as well as compatible) on a Mac II with 5 meg of RAM under MultiFinder 1.0. When I Run the project, it opens up in a MultiFinder partition of its own, with the size determined by the SIZE resource in the Project file; when I compile it down to an application, it uses the SIZE resource in the Project.rsrc file (so those two can be different, which is good). I also run ResEdit at the same time, leaving the window for the disk open (the Project.rsrc file must be closed in ResEdit to Run in LSC, and the project must not be running to open the file in ResEdit. Making either mistake seldom causes a crash.). This has got to be the current ultimate C development system for the Mac. I don't even have to exit the editor to change the resources, something I ALWAYS had to do (until LSC w/Switcher, which I used before). This makes it much easier to write good, portable, Mac Code, since I can easily see what ID's things have, and I can modify the resources easily to help debugging (make my Windows all visible by default so I can see the setup activity, for instance). The only thing LSC doesn't do is compile in the background (or even allow task switching during compiling). That would be nice. -Eric I am not affiliated. Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
gillies@uiucdcsp.cs.uiuc.edu (12/18/87)
I played with a few compilers (mostly I looked at manuals) at our
university software evaluation room yesterday. I got this impression
from a brief reading of the manuals:
1. Manx (Aztec) C seems *very* UNIX-oriented. The manual gave me the
impression the product was not well integrated. For instance, you are
supposed to run things from a UNIX-like JCL shell. A lot of the
PC-like MANX manual is devoted to describing the UNIX shell they have
reimplemented on the mac.
2. Turbo Pascal seemed to be a very fast compiler, but it didn't look
like it had facilities to build large programs -- e.g. it was set up
to compile one huge program file in memory, and that is all.
Quickdraw documentation is very sparse.
3. I haven't been able to look at a lightspeed C or Pascal compiler.
I've seen a little bit of Lightspeed's Pascal manual, and it looks
like it has an integrated *make* command with functionality similar to
UNIX's (but for compilation only). Is the C *make* stuff similar? I
am attracted to the lightspeed manual because it seems to document
quickdraw/system calls extensively (can this manual substitute for
large hunks of "inside macintosh"?) Also, the latest update
supposedly provides full Mac II color quickdraw/multifinder (.h)
files/compatibility?
I have often heard that LightspeedC is one of the best C compilers for
the Mac, but I'm wondering if other products surpass Lightspeed in
some small areas (but not overall). I'd appreciate any info on this
subject. And will summarize if there is interest.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}jmunkki@santra.UUCP (Juri Munkki) (12/22/87)
What I would like to have in Lighspeed C is global register variables. It shouldn't be too hard to implement since LS C already supports A5 and A4 based global variables. The application I'm working on has a lot of concurrently working windows with their own variables. I'd like to have a global pointer to the local variables in a register for faster access. If a method exists, please tell me...if one doesn't, please consider adding it to the wishlist. A 32K limit would not bother me at all. Juri Munkki jmunkki@santra.hut.fi jmunkki@fingate.bitnet