Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cmu-cs-spice.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!cmu-cs-pt!cmu-cs-spice!tdn
From: tdn@cmu-cs-spice.ARPA (Thomas Newton)
Newsgroups: net.micro.mac
Subject: Re: C compiler survey
Message-ID: <365@cmu-cs-spice.ARPA>
Date: Wed, 1-May-85 19:47:48 EDT
Article-I.D.: cmu-cs-s.365
Posted: Wed May  1 19:47:48 1985
Date-Received: Sat, 4-May-85 03:55:27 EDT
Organization: Carnegie-Mellon University, CS/RI
Lines: 174

This is a reply to the C compiler survey request that was posted a while back.
I'm using Megamax C version 2.0 on a 128K Mac with an external disk drive.

        1) any extensions to K&R?

Several:
  - In-line assembly language, using the syntax:
        asm {    . . .
                MC68000 assembly language instructions
                 . . .
            }
  - Structure/union assignment and passing
  - By putting 'pascal' in front of the declaration of a procedure, you
    can force the compiler to follow Pascal stack conventions, which is
    useful when you want to pass procedure parameters to a ROM routine.

I think that there is one restriction, though: you've got to declare static
functions before using them, due to the one-pass nature of the compiler.

        2) what system functions (sprintf(), etc.) are available?
I haven't really worked much with C/Unix systems, but it seems to have a fair
number of Unix-like functions (toascii, atoi, printf, fseek, getc, putc, etc.)
The manual does warn that sbreak (sp?) is not Unix-compatable; in particular,
sequential calls to sbreak are not guaranteed to return adjacent memory blocks.

        3) how much of the Mac toolbox is supported & how well (C vs P strings)
I think that it supports either the full toolbox, or nearly all of it.  It does
take care of many string conversions automatically.  There are also functions
to convert between Pascal strings and C strings which you can call if needed.

        4) what is user interface like? (UNIX or Mac?)
I've heard that earlier versions required the user to type in filenames, but
version 2.0 uses a Mac-like user interface.  A batch program is included that
runs a list of programs in order; it works with any Mac program but is only of
real use with programs that can run non-interactively and return error codes.
Since the compiler, linker, etc. meet these criteria, you can do other things
while the Mac automatically recompiles & relinks the modules in your program.
Now if I can just manage to port the PERQ version of make (written here). . .

In fact, my main complaint against the compiler is that the editors included
with it (Apple's FILE and Consulair's EDIT) are too mouse-oriented; they don't
have any keyboard commands for common operations like moving the cursor around.
But I haven't heard of any C compiler that does differently -- licensing FILE,
EDIT, and RMAKER must be fairly cheap compared to the cost of writing new ones.
So this isn't a comparative disadvantage with respect to other C compilers.

        5) can it create "double-clickable" routines?
Yes.  The linker can be told to produce either a "double-clickable" file (by
default) or a resource file containing a desk accessory.  There doesn't seem
to be full support for creating other types of code resources (PACK come to
mind).  The desk accessories created don't seem to have the 'purgable' bit set
(which would allow the Mac to throw them out of memory when space gets tight
and reload them later).  I'm not sure what issues are involved here; it could
be that there is a good reason for making the default non-purgable.

        6) what support routines are available (debuggers,lint,context editor)
In addition to the compiler, the code improver, and the linker, the Megamax C
Development System comes with

        FILE and EDIT                mouse-oriented editors; EDIT can
                                     work with files larger than memory
        RMAKER                       Apple's resource maker
        MMLIB                        allows you to build your own libraries
        DIS                          disassembles the .o files produced by
                                     the compiler (unlike many of the others,
                                     MMC doesn't use a separate assembly pass)
        SIZE                         I think this one tells how much executable
                                     code resides in a .o file.

Also, the system file on the MMC disk has a 'Transfer' accessory installed.  I
don't like Transfer very much; unlike SkipFinder, it doesn't give the currently
executing program a chance to clean up open files, etc.  Megamax warns against
using it from inside the Consulair editor for just this reason.  I plan to put
the new SkipFinder into my System file and just ignore Transfer altogether.

However, transferring between programs in the Megamax C system is fairly easy.
The compiler, linker, and code improver all invoke the transfer accessory after
they have finished doing their work, when it is safe to use it.  The Consulair
editor has been modified so that its transfer menu shows the C compiler and the
linker.  I don't use File much, since it can't handle long documents and since
the version on the Megamax C disk doesn't have the "Utah" improvements.  It is
interesting to note that although the MacModula people claimed that they could
not get permission to modify Edit's TRANSFER menu, Megamax didn't seem to have
any problems.

Sources to the standard libraries cost $50, and a 'developer support service'
costs $150.  I'm not sure exactly what the latter includes.  There isn't any
debugger, either as part of the standard package or as an option.  I haven't
tried using the MDS/Supplement 68K debuggers on Megamax C programs; it might
be possible to do object-level debugging.

I have heard that later copies of version 2.0 come with the Megaroids game;
I bought my copy on the day that MMC 2.0 arrived at the CMU Computer Store.
Megaroids is a very nice implementation of Asteroids; it's absolutely free
and can be passed around (but not sold) to anyone.  Sources are available
for $25 (although I get the impression that if you wanted to slightly modify
the game, you would need to type them into your Mac from a paper listing).
The people at Megamax deserve many thanks for giving away this great game;
here's hoping that it'll do for the sales of Megamax C what Visicalc did for
the sales of the Apple II, or what Star Raiders did for the Atari 400/800.

        7) compilation speeds, linking speeds, execution speeds
Compilation is very fast.  Linking is so-so, but considering that the linker
is actually throwing out the parts of libraries that it doesn't need, not too
bad.  I haven't written any large & time-consuming programs yet (too much work
to do at school...), so I can't give you an estimate on execution speeds.  If
I'm remembering the comparison posted a month of so ago correctly, Megamax C
produced the fastest-running programs of the C compilers tested.

        8) compiler intelligence (optimizer?, good error diagnostics)
I haven't seen a compiler yet which produces good error diagnostics (including
the one which I am working on at school), with the possible exception of PL/C,
which seems to be determined to push programs through to execution, regardless,
and actually tries to "correct" erroneous programs.

There is a separate "code improver" which can be invoked on the .o files that
are produced by the compiler; in addition, the compiler does some optimizations
right away.

I could run a simple C program through the compiler, and post the disassembly
listings (from the compiled code & from the compiled/optimized code) if you'd
like to see what sort of code it generates.

        9) linker intelligence (size of produced object)
The linker spends some time deciding which library routines it needs to pull
in; this probably leads to a win in the size of the object files.

       10) any limitations to source size, number of files, etc.?
On a 128K Mac, the compiler uses screen memory to hold the symbol table once
it has filled up the rest of the available memory.  Many times, I have seen
the symbol table go fairly far down the screen; this happens most often when
importing a lot of header files.  On a 128K Mac, there probably is a limit.
On a 512K Mac, I doubt if you'd have any problems (other than disk capacity,
which is a function of the drive, rather than of the compiler).

        11) does it create 68K assembler code, P code, or just binary
It creates 68K object code.  The ".o" files that are produced by the compiler
contain some symbol table information which allows the disassembler to display
symbolic labels.

        12) any required (suggested) hardware or software over a 128K Mac?
It will run on a one-drive, 128K Mac -- but probably very painfully.  I would
recommend having at least an external floppy (or a hard disk).  I don't know
how important it is to have 512K of RAM when writing large programs.

        13) royalties, copy protection, source code availability
No royalties.  No copy-protection.  There's not even one of those common bogus
"licensing agreements" inside.  Just a copyright notice and the usual warranty
disclaimer (media for 90 days, software for zilch).  A refreshing change from
the usual "screw the customer if s/he wants to make backups or use a hard disk"
type of attitude.

        14) anything else -- documentation, support, ease of use
One of my two originals went bad shortly after I got the compiler ('this disk
is unreadable -- eject/initialize').  I sent it back to Megamax to be replaced
about a couple of weeks ago; the replacement arrived yesterday.  Since one of
the first things I had done after opening the shrink-wrap was to make a backup
copy, I was able to use the compiler in the meantime.

I was a little surprised when I first looked at the documentation -- most of it
looks like it was printed on an Imagewriter, and the rest appears to have been
photocopied straight from the MDS documentation.  One sheet had holes punched
on the wrong side of the paper and was inserted upside down.  But it does seem
to contain the necessary information in most cases (it doesn't go into a lot of
detail about how to make "PACK", "INIT", etc. code work, and the linker only
takes care of programs and desk accessories automatically).

Applications created by Megamax C don't work with SkipFinder versions 4.3 and
earlier; since SkipFinder 4.3 seemed to work with all of my other programs, I
thought that the compiler might be at fault.  However, there is now a version
of SkipFinder (5.1) which will work with Megamax C programs; end of problem.

                                        -- Thomas Newton
                                           Thomas.Newton@cmu-cs-spice.ARPA