emil@rochester.UUCP (03/26/85)
From: Emil Rainero <emil> >I would appreciate most >to hear from someone who has tried BOTH of these compilers. But in lieu of >some generalist comments, anyone having tried and liked either would have >my undying gratitude for helpful comments. > >THINGS TO CONSIDER: > > 1 - Price > 2 - Convenience of using the product. (i.e. how closely does it > conform to both the standard Mac interface.) > 3 - How closely does the product come to K & R specifications. > 4 - Does the product have good debugging tools (symbolic debugger, etc.) 5 - What about the linker and librarians. > 6 - Can all toolbox routines be accessed? > 7 - What quality of code generation does the compiler give? > I've used both. I started with Mac C about three months ago and megamax C about two weeks ago. What follows are my very biased opinions. Consulair Mac C Disadvantages: 1. No debugger (all C compilers share this misfeature) 2. No sfputfile/sfgetfile/create/fswrite/fsread To be fair, the assembler knows about these toolbox calls and appropriate library routines could be written. 3. resource maker is very minimal (all on the mac are) 4. no floating point 5. no register variables 6. My biggest complaint is two pass compiling. By this I mean producing an assembly language listing and then assembling it. Just to give you an idea of how time consuming it is, here is how a normal compile goes. From the editor we invoke the exec program on a file that says what to compile/assemble/link. The normal 15 second delay before we even enter the compiler. Now about 15 more seconds to do the compile and to write an assembly language listing to disk. From the compiler we get zapped into the assembler (15 more seconds) wich then reads in the assembly language listing and takes about 15 more seconds to assemble and write out a rel file of our code. Now another 15 seconds to invoke the linker and another 15 seconds to link out files and another 15 seconds to get back to the editor. By the way, then linker is very fast and stupid, so entire libraries get loaded with your code. Megamax C Disadvantages: Megamax C shares some of the problems of Consulair. 1. No debugger (all C compilers share this misfeature) 3. resource maker is very minimal (all on the mac are) 6. Takes about as long as consulair to get a running C program. Compiling is not much faster and the linker is painfully slow for a generic macintosh program. 7. all lower case toolbox (while convertible to mixed) is not standard. Consulair Mac C Advantages: 1. register based calling should be faster than Megamax C 2. ditto for parameter accessing 3. having the 6800 MDS is very important for any serious mac development. 4. mixed upper and lower case toolbox is Apple Standard Megamax C Advantages: 1. full toolbox available 2. mac SANE floating point 3. object code improver (haven't tried it) 4. register variables 5. code segmenting FINAL COMMENTS I prefer Megamax C by a very small margin. Having the full toolbox and floating point is crucial for my work. Both have reasonable mac user interfaces, assembly level macsbug debugger, minimal rmaker, inline assembly code, edit, batching. I think the "Bat out of hell compiling" of Megamax C is not an issue if you are doing mac development as opposed to standard C development. I didn't notice and real difference in total turnaround time using either system. My biggest problem with any of the C compilers is the extra hassles converting between Pascal and C strings. A desk accessory demo would be nice. If Consulair Mac C would come out with a floating point version with segmentation and full toolbox support I think the scales will tip in their favor. Emil Rainero UUCP: (..!{allegra, decvax, seismo}!rochester!emil) ARPA: emil@rochester.arpa USmail: Emil Rainero, Dept. of Comp. Sci., U. of Rochester, NY 14627. Phone: Office: (716) 275-5365 Home: (716) 424-5016
lat@druxx.UUCP (TepperL) (03/29/85)
I had an opportunity to look at the Megamax C manual. As I understood one
of the early chapters, sizeof(short) == 1. Is this really the case?
Could a bonafide Megamax user verify or refute this?
In particular, this would be a hassle if you wanted to port some programs
written for the UNIX C compilers for the PDP-11, VAX and other machines.
For those not familiar with these compilers, here's the story:
PDP-11 VAX IBM-370
sizeof(short) 2 2 2
sizeof(int) 2 4 4
sizeof(long) 4 4 4
In addition, I know there are a GAGGLE of 68000 C-compilers out there
for which sizeof(short) == 2. If you've written programs to run both
on the PDP-11 and on the VAX, it's a common practice to specifically
use short-ints for items requiring "about 16 bits". The same thing
applies for all those other 68000 C compilers.
Was this just a typo in the manual? Hope so. Yes, yes, I know that K&R
doesn't specifically prohibit such a small short-int. But if this is true,
there is a bunch of code that will require some heavy type-def'ing or cpp'ing
to port correctly just for this one compiler.
--
Larry Tepper {ihnp4 | allegra}!druxx!lat +1-303-538-1759jimb@amdcad.UUCP (Jim Budler) (03/31/85)
In article <678@druxx.UUCP> lat@druxx.UUCP (TepperL) writes: >I had an opportunity to look at the Megamax C manual. As I understood one >of the early chapters, sizeof(short) == 1. Is this really the case? >... >In particular, this would be a hassle if you wanted to port some programs >written for the UNIX C compilers for the PDP-11, VAX and other machines. >... I just thought I would clarify Consulair Mac-C's place in this discussion and mention that I do know that Megamax sizeof(int) is 2. PDP-11 VAX IBM-370 Mac-C(default) Mac-C(option) sizeof(short) 2 2 2 2 1 sizeof(int) 2 4 4 4 2 sizeof(long) 4 4 4 4 4 Bill Duvall( Consulair ) states in the manual that the default of 16 bit shorts and 32 bit longs is for portability and that the option of 8 bit shorts and 16 bit int's is optimum for the architecture of the 68000 and generates faster, more compact code. -- Jim Budler Advanced Micro Devices, Inc. (408) 982-6547 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!jimb Compuserve: 72415,1200 The Source: STW265
tim@callan.UUCP (Tim Smith) (04/01/85)
In article <7606@rochester.UUCP> emil@rochester.UUCP writes: >1. No debugger (all C compilers share this misfeature) Really? Then what was I recently doing with the debug window in Hippo-C? By the way, do all of the C compilers for the Mac have any of the post K&R extensions such as structure passing/assignment? I already know that Hippo does, but what about the rest? -- Duty Now for the Future Tim Smith ihnp4!wlbr!callan!tim or ihnp4!cithep!tim