🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

4 total messages Started by emil Tue, 26 Mar 1985 18:48
Consulair Mac C vs. Megamax C
#987
Author: emil
Date: Tue, 26 Mar 1985 18:48
107 lines
4681 bytes
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
Re: Consulair Mac C vs. Megamax C
#1005
Author: TepperL
Date: Fri, 29 Mar 1985 19:29
25 lines
1762 bytes
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-1759
Re: Consulair Mac C vs. Megamax C
#1017
Author: Jim Budler
Date: Sat, 30 Mar 1985 21:39
27 lines
1731 bytes
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
Re: Consulair Mac C vs. Megamax C
#930
Author: Tim Smith
Date: Mon, 01 Apr 1985 19:56
12 lines
1132 bytes
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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads