santiago@ny1mm.DEC (Carlos D. DTN 333-6249) (04/16/86)
Hello world, I've seen various mentions on our own internal network (Easynet) about the various C compilers for the Macintosh. Has anyone see a complete (up to date) listing, that covers such topics such as: 1) compilation speed NOT USING A HARD DISK 2) linker intelligence 3) adherence to K&R 4) produces 'clickable' applications 5) supports float & double 6) supports TYPEDEF 7) for that matter passing structs by ref? I'm new to the world of Macintosh (a VAX/VMS hacker for some time), and am familiar with lattice, CIC on ms-dos; ...>Carlos D. DIGITAL EQUIP. CORP. 1 PENN PLAZA, NYC NY 10119
chuq@sun.uucp (Chuq Von Rospach) (04/16/86)
> I've seen various mentions on our own internal network (Easynet) about > the various C compilers for the Macintosh. Has anyone see a complete > (up to date) listing, that covers such topics such as: > > 1) compilation speed NOT USING A HARD DISK > 2) linker intelligence > 3) adherence to K&R > 4) produces 'clickable' applications > 5) supports float & double > 6) supports TYPEDEF > 7) for that matter passing structs by ref? Well, there are a number of C compilers. Based on comments here and on CompuServe, the compilers to look at are 'Mac C' by Consulair, Lightspeed C (a new compiler), Aztec C and Manx. I use Mac C (currently 4.0, but I've owned it since 1.0). It works fine on a pair of floppies (NOT recommended for a single 400K machine, although I can't think of ANY serious development system that would try that). Speed is reasonable, and I'm really looking forward to my upgrade so I can use an 800K floppy. 4.0 and later has a smart linker so you don't link in routines that aren't used. Object format is MDS, so you can use everything from Apple without hassle (like macintalk, for instance). It stays very close to K&R, generates standalone applications, uses float and typedef. It was one of the first development systems for the mac and still the one most people try to compare to. It has a full toolbox support package so you can access all the ROM stuff, and a release is out that handles HFS (last I saw, this was NOT true of other compilers). chuq -- :From the lofty realms of Castle Plaid: Chuq Von Rospach chuq%plaid@sun.COM FidoNet: 125/84 CompuServe: 73317,635 {decwrl,decvax,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!plaid!chuq The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do -- McCloctnik the Lucid
clif@intelca.UUCP (Clif Purkiser) (04/18/86)
> > Hello world, > > I've seen various mentions on our own internal network (Easynet) about > the various C compilers for the Macintosh. Has anyone see a complete > (up to date) listing, that covers such topics such as: > > 1) compilation speed NOT USING A HARD DISK > 2) linker intelligence > 3) adherence to K&R > 4) produces 'clickable' applications > 5) supports float & double > 6) supports TYPEDEF > 7) for that matter passing structs by ref? > > I'm new to the world of Macintosh (a VAX/VMS hacker for some time), and am > familiar with lattice, CIC on ms-dos; > If you like Unix-like development environment you should also consider the DeSmet/Ouye C complier from C-Ware Corp. It includes: Complete K&R implementation (supports 1-6 on you list possibly 7) Transparent access to the ROMToolbox Linker, Librarian, & Assembler Unix-like shell (history commands, batch files etc) Screen editor, and a few examples Video Game (MacBugs!), RamDisk etc. All for $150 I like it better than my roommates Mac C. He hates Unix and likes Mac C better. I have found that it the fastest system to complete an edit, compile, link, execute cycle because you can fit everything onto a RAMDISK on a 512K Mac I think it is very comparable to Manx/Aztec at 1/3 the cost. *** REPLACE THIS LINE WITH YOUR MESSAGE *** -- Clif Purkiser, Intel, Santa Clara, Ca. HIGH PERFORMANCE MICROPROCESSORS {pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!clif {standard disclaimer about how these views are mine and may not reflect the views of Intel, my boss , or USNET goes here. }
berry@tolerant.UUCP (David W. Berry) (04/19/86)
In article <2392@decwrl.DEC.COM> santiago@ny1mm.DEC (Carlos D. DTN 333-6249) writes: As far as LightspeedC is concerned > > 1) compilation speed NOT USING A HARD DISK Easily 250-500 Lines per second from 800k floppies. Even faster if the compiler and includes are on a ramdisk. > 2) linker intelligence Unfortunately not as bright as it could be. Indications are that they sacrificed this to meet release schedules. > 3) adherence to K&R They claim complete. I haven't noticed any inconsistencies. > 4) produces 'clickable' applications As an extra step. Part of the edit-recompile-test cycle speed is that a complete application isn't built for every cycle. Extra time to build a large application is measurable in seconds. > 5) supports float & double Yes. double is 80-bit extended IEEE (using SANE). > 6) supports TYPEDEF Yes. > 7) for that matter passing structs by ref? Passing of structs by ref and return of structs are both supported. In addition: 1) Has a blindlingly fast edit/recompile cycle. 2) Supports enum, pascal function modifier and inline toolbox traps. 3) Editor/Compiler are a single package occupying 173K. 4) The editor supports unix style full regular expression search and replace. 5) There is a multi-file search and replace capability that is rather well implemented. 6) The package has a built in make facility. It isn't unix make, nor is it as powerful, but it quite adequate for it's purpose. 7) It will generate applications, da's/drivers, and pure code resources. It even allows initialized globals in da's. Defects: 1) Doesn't yet support added traps in the new roms/HFS. It runs under HFS but you can't write programs to use the new calls as delivered. I have a set of glue routines and header files that fixes the problem though. 2) Doesn't have inline assembly. Nor does it integrate well with MDS. You have to assemble the file with MDS and then run a program they supply to convert to a useable format. They do provide a method of mapping the single case MDS names to the dual-case names they use. 3) It breaks when run under heap scramble in TMon which means it might have lot's of trouble on a 128K mac or in a small switch segment. The again, so does Finder 5.2. If you need/want more information feel free to contact me by mail at: -- David W. Berry dwb@well.UUCP Delphi: dwb {ucbvax,pyramid,idsvax,bene,oliveb}!tolerant!berry I'm only here for the beer.
tim@ism780c.UUCP (Tim Smith) (04/19/86)
In article <3517@sun.uucp> chuq@sun.uucp (Chuq Von Rospach) writes: > >I use Mac C (currently 4.0, but I've owned it since 1.0). It works fine >on a pair of floppies (NOT recommended for a single 400K machine, although >I can't think of ANY serious development system that would try that). Speed Before I got a Hyperdrive, I used Megamax C on a 512k Mac with no external drive. A ramdisk can take the place of an external drive. It takes some experimenting to find the best configuration ( "Let's see, should I put the system/finder in RAM, or the linker and the library. Wait, maybe I should put the include files there..." ). The main problem with this is that if your program bombs, you lose the ramdisk. I suppose if you are developing an application that needs 512k, testing it might be a hassle. Some suggestions for people looking for C compilers: 1. The "big-names" in Mac C compilers are Consulair, Manx, and Megamax. These have all proven themselves to be good systems. You can't go wrong with any of these. As Chuq mentioned, Consulair supports HFS. Megamax now _almost_ does ( they are having problems with one of their utilities ). I don't know about Manx, but I would be very surprised if they are not close to the others. 2. There has been a lot of fuss about LightspeedC. It is new so there are still some bugs. However, look at the benchmarks it gets! Wow! 3. MacTutor has a lot of articles for C programmers. Each issue usually has source code for one or two of the above compilers. It might help to read these. Then again, it might not :-) 4. Use the telephone. Decide what features you want, and then call the companies and ask about them. 5. Interesting fact #1: Most people who admit to owning Softworks also have another compiler, bought _after_ they bought Softworks. 6. Interesting fact #2: No poufters! -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
bngofor@mmm.UUCP (MKR) (04/19/86)
>Well, there are a number of C compilers. Based on comments here and on >CompuServe, the compilers to look at are 'Mac C' by Consulair, Lightspeed >C (a new compiler), Aztec C and Manx. Just a clarification - Aztec C is put out by a company called Manx Software Systems - the last two on the list above are the same thing. -- --MKR "They're not so much *songs* as exercises in tonal breath control." -Dylan
kearns@garfield.columbia.edu (Steve Kearns) (04/21/86)
does the fact that lightspeed C programs do not work well under heap scramble imply that their memory management routines are buggy?
waddingt@umn-cs.UUCP (Jake Waddington ) (04/22/86)
a
A question about Light Speed C:
If you can convert MDS format files, can you call TML Pascal functions?
TML does not support "UNITS" but I beleive one can make libraries with
the new linker or just edit the aasembly code produced by the compiler.
So how hard is it to call MDS functions from Ligth Speed C ?
Thanks,
Paul Fink
ihnp4!umn-cs!waddingt
gus@Shasta (04/29/86)
> does the fact that Lightspeed C programs do not work well under heap > scramble imply that their memory management routines are buggy? Not exactly buggy, but slow. I am doing a benchmark on various C compilers. Although the final results aren't in yet, one thing is clear. Calls to malloc should NOT translate directly into Mac memory manager calls. Aztec, Lightspeed, and Consulair do this while Megamax and Lisa Workshop C have a two-stage malloc. As a result, 5,000 element treesort takes about 300 seconds on the former set and 5 seconds on the latter. Lightspeed has two sets of storage allocation routines. The first set (malloc, free) take linear time to execute in the number of consecutive calls, while the second set (getmem, freemem) exhibit the constant time performance which allows treesort to work at the expected n log n speed. Now some might say that you really shouldn't be using standard C routines for Mac code. The storage allocation primitives, however, are arguably an exception which should not be overlooked. These routines SHOULD be optimized to be as fast as possible and still use the Mac heap architecture. The best way to do this is to provide a two-level memory allocation heirarchy which allocates LARGE blocks from the memory manager, and splits these up into small blocks as requested by the user. Gus Fernandez
jimb@amdcad.UUCP (Jim Budler) (05/03/86)
In article <464@Shasta.ARPA> gus@Shasta.ARPA (Gus Fernandez) writes: >Now some might say that you really shouldn't be using standard C routines >for Mac code. The storage allocation primitives, however, are arguably >an exception which should not be overlooked. These routines SHOULD be >optimized to be as fast as possible and still use the Mac heap architecture. >The best way to do this is to provide a two-level memory allocation heirarchy >which allocates LARGE blocks from the memory manager, and splits these up >into small blocks as requested by the user. Sounds like a surefire way to run out of memory. I suggest you remove the term 'the best' above and replace it with something like 'one way I like'. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200