Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ames!oliveb!epimass!csi!jwhitnel From: jwhitnel@csi.UUCP (Jerry Whitnell) Newsgroups: comp.sys.mac Subject: Re: C and large data model (long) Message-ID: <1325@csib.csi.UUCP> Date: 17 Dec 87 19:48:43 GMT References: <8712152132.AA10832@decwrl.dec.com> Reply-To: jwhitnel@csib.UUCP (Jerry Whitnell) Organization: Communications Solutions Inc., San Jose, Ca Lines: 135 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?