START'S FIRST C COMPARISON
by Arick Anders and Michael Bendio
START compares the four available ST C languages: Alcyon, Lattice, Megamax, and GST- including revealing benchmarks plus a critical analysis of each compiler's methods, documentation, editors, and extras.
Comparisons are odious - and often misleading. This is especially true of programming languages. No matter what yardsticks are used, certain elements of the test are bound to be unfair to various implementations. But language comparisons provide necessary and valuable guidelines to both the serious developer and the dedicated hobbyist.
One way to compare C's is to first determine the features of the "perfect" compiler then find a way of evaluating these features objectively. Easier said than done. A number of tests, called "benchmarks," have been developed to quantify these features. The best known-the Sieve of Eratosthenes- measures a compiler's ability to manipulate several variables rapidly. But benchmarks often do not accurately measure what they appear to measure. For example, the following code was once used to measure a compiler's ability to manipulate pointers:
strien(s) /* returns the length of s char *s;
{
char *p;
for( p = s; *s != '\0'; s++);
return(s - p);
}
This really tests the efficiency of the for loop. The amount of time
spent doing pointer manipulations is trivial compared to the time spent
executing the loop.
Distinguishing between a compiler that generates good code and one that uses an efficient library is important. If you rarely use library calls, a poor compiler with a fast library is not the one for you.
DHAMPSTONE
Of all the generic benchmarks published over the years, the best we have seen is Dhampstone, by Jack Purdum. Dhampstone, first published in the February, 1986 issue of Computer Languages, is actually several benchmarks in one. It avoids library calls and does a good job of testing specific features of a compiler. And all of Dhampstone's subroutines return a value which helps the programmer verify if the compiler generates correct code. We added timing routines for the GST C test and modified the program to run on the Atari ST (Look in the BENCHMRK.STQ folder on your START disk for the Dhampstone source code.) In all cases, each compiler returned the correct values from the subroutines, so no indication of the returned "magic" numbers is included in our charts.
The peculiar name for this benchmark is a tongue-in-cheek reference to two other benchmarks. The Whetstone benchmark is a well-known measure of floating-point performance from the mainframe world, and the Dhrystone benchmark, written by C. Weicker, and published in CACM (Communications of the ACM magazine), is based on a study of keyword frequency in programs written in several different languages. The Dhrystone benchmark attempts to show the distribution frequency of these keywords. Purdum, however, made a similar study of keyword distribution directed specifically at C in some 15,000 lines of C code from the Digital Equipment Corporation User's Group in Marlboro, Massachusetts. He found significant differences in C keyword distribution from Weicker's study. The Dhampstone benchmark reflects Purdum's findings for C's keyword distribution. It includes tests of string handling, arithmetic involving integers, unsigneds, longs, doubles, and disk I/O. The unsigned test also checks a compiler's ability to handle recursion by finding Fibonacci numbers (a series in which each number is the sum of the previous two, i.e., 1,1, 2, 3, 5, 8,13, etc.). While these are simple trials, they do a good job of testing a compiler in its critical tasks.
DOODLE
To test GEM compatability, we used DOODLE, the paint program included
with the Developer's Toolkit. This is a good example of a typical GEM application
in terms of size and usage. It also revealed some interesting violations
of programming standards. For example, Alcyon C will allow a pointer to
be assigned to a nonzero constant or to a variable. Kernighan & Ritchie
specifically forbid this. With the pickier compilers, such as Megamax,
it causes portability problems. It also uses long integers as pointers.
these products,
there are astounding
differences in the
compile and link
times.
The greatest portability concern we encountered resulted from the lack of a standard size for an integer variable. Lattice and GST use a 32-bit integer; Alcyon and Megamax use a 16-bit integer Both the new ANSI standard (see below) and Kernighan & Ritchie define an integer size as the "most convenient" size for a particular machine. Historically, integers have been the same size as pointers, but there is no real reason they should be, especially since making integers the same size as pointers tends to promote programming abuse. Since the 68000 is a 16-bit processor and 32-bits requires two memory fetches, we have to agree with Alcyon and Megamax in choosing 16-bits for the default size.
The quickest way to categorize the available ST compilers is to decide if you need a simple compiler or a full GEM developer's kit. Alcyon and Megamax offer GEM developer's kits which include resource construction sets and full GEM documentation. Lattice and GST are compiler packages. They can be used to produce GEM applications, but with more difficulty.
Among these products, there are astounding differences in the compile and link times, and the size of the executable programs. One reason GST's size on the Dhampstone is so much larger is that it always includes code for windowing. Megamax's times are so much quicker because it is a single-pass compiler and doesn't have to wait on disk I/O for intermediate files.
In evaluating each compiler, we have tried to identify the best features of each and express its basic "feel." We have left most of the performance evaluation to the benchmarks (see our accompanying charts). The quantitative differences between the compilers are quite distinct.
ANSI
Recently, the American National Standards Institute (ANSI) established the X3J11 committee to define a standard for the C language. In addition to clarifying many ambiguities in C as defined in "The C Programming Language" by Kernighan and Richie, the committee has added several new features to the language which are beginning to show up in new releases of C compilers. These include the "void" data type for functions which don't return significant values, enumerated data types, structure assignment, the use of "unsigned" as a modifier for other data types, and perhaps most importantly, function prototyping.
A frequent source of errors can be traced to adding or deleting arguments to functions and failing to make corresponding changes to all of the calls to those functions. In the past, C compilers have blithely compiled such errors without complaint. On the first call with mismatched parameters though, the program suddenly begins executing parameters or passing code-with disastrous results. Function prototypes allow the programmer to declare the number and type of a function's parameters, and the type of its return value. With this information the compiler can detect and warn of mismatched parameters. Lattice C implements all these ANSI extensions. Its function prototyping allows it to detect the wrong number of parameters, and it will complain if you pass a pointer to an int instead of an integer. However, it remains silent if you pass a char to an int; it would be nice if the type-checking here were stricter.
FLUCTUATIONS
As dynamic as the ST is it is hardly surprising that, within the time this review was written, one C compiler had been withdrawn from the market and one was being introduced. Our review will cover the four compilers that are currently being marketed: Lattice, Alcyon, Megamax, and GST. Many people are familiar with Hippo-C from Haba Systems. We talked with Pat Merrifield from Haba and he informed us that Hippo-C is no longer being marketed by Haba Systems. Hippopotamus Software originally developed Hippo C for in-house use. Haba Systems purchased the tights from Hippopotamus to finish and market it. Haba subsequently released it, but after receiving a flood of error reports, withdrew it from the market.
On a more positive note, Mark Williams, of Mark Williams Company, manufacturers of Let's Write, indicated that he is developing a C compiler for the ST. Unfortunately it was not ready in June 1986, when this article was written. Mark Williams is well known in the world of minicomputers. He also has a compiler on the IBM PC which is one of the few available on a microcomputer with a source-level debugger START will examine this compiler package when it becomes available.
LATTICE C
Anyone who has worked with C in the MS-DOS environment will recognize and welcome Metacomco's introduction of Lattice C to the Atari ST marketplace. Although Microsoft C is currently challenging Lattice C for market leadership on the IBM PC, it is probably safe to say that more applications have been written with Lattice C than any other MS-DOS C compiler. Thus, the Atari ST version of Lattice C will particularly interest anyone considering a port of an MS-DOS application to the ST.
Lattice's recent 3.0 release for MSDOS was a major upgrade from the 2.x versions in two areas. It added the new ANSI C language extensions, and included an improved, more UNIX-compatible library. We were glad to see that the ST version included the ANSI extensions. This indicates to us that the compiler portion of the ST product is Lattice's newest and best. The library, however, is definitely the equivalent of the older 2.x MS-DOS library rather than the newer 3.0 release. This really amounts to saying that the library is merely very good instead of being excellent. The function index for this implementation has more than 130 entries covering memory allocation, I/O, utilities, string handling, and math functions.
DOCUMENTATION
Documentation for Lattice C consists of a paperback manual of about 250 pages. It includes a two-page table of contents, five appendixes, and an eight-page index. Two of the appendixes thoroughly document error messages and even suggest possible sources for the errors. The remaining appendixes include example programs, a function index, and documentation of the GEM VDI/AES interface. The manual itself contains sections on the editor, the linket the language definition, and machine dependencies in the code generation. The bulk of the manual-a full half of it-is devoted to UNIX-style documentation of the library. Each library function has its own page with sections explaining its purpose, giving its synopsis and description, specifying its return value(s), and noting any relevant cautions.
A major weakness in the manual is its documentation of the VDI/AES interface,
which is relegated to a 16-page appendix. Each entry includes a routine
name plus a short phrase describing its action. Arguments for the routines
are listed, but not the argument types or legal values. This appendix seems
intended only as a guide to the heavily commented assembly-language source
code for the VDI/AES calls, provided on the disk. Although the source provides
much more information about arguments and how to use the routines, the
information is still woefully inadequate by itself.
glad to see that
the ST version of
Lattice included the
ANSI extensions.
GEMDOS, BIOS, and XBIOS calls allow access to machine-specific parts of the ST operating system. These vital interface routines are documented by Lattice with only a single page each. But it's hard to fault Metacomco for this poor documentation when the blame should really be placed at Atari's door. VDI, AES, and the GEMDOS, BIOS, and XBlOS should be thoroughly documented in a series of manuals available from Atari at a reasonable price. To make this information available only to developers, and only with $300 worth of bundled software is unprofessional and counterproductive. IBM has set a standard for thorough and freely available documentation that Atari would do well to follow.
USE
Creating an executable program with Lattice C is a two-step process. First, you invoke the compiler-driver, LC, which opens a dialog box prompting you for a single file name and any command line specifiers you wish to use. LC, in turn, executes the two phases of the compiler: LC1, which parses the source and outputs a quad file, and LC2 which generates the code. The second step is linking, using the GST linker that Metacomco supplies. Again, you use a dialog box to pass a command line to the linker. The linker is identical to the one included in the GST C package.
Several compile-time options can be specified when running LC. You can redirect error and warning messages to a specified file by using >filename. The -dsymbol or -dsymbol = value options define the identifier "symbol." This can be used to trigger conditional compilation directives in the code (#ifdef, #ifndef, etc.). Although the default effective length for identifiers is eight characters, you can override this with the -n option which causes the compiler to use up to 31 characters to differentiate identifiers. Stack overflow bugs can be extremely difficult to diagnose. The -p option causes the code generator to insert a special instruction known as a "stack probe" at the entry of each function. If the stack overflows, this code detects it and aborts the program with a "stack overflow" message. After you're sure your code is clean, you can recompile without the stack probe option. This can save you hours of debugging. The -i option is useful for specifying in which directory the compiler should search for #include files.
EDITOR
The editor provided with Lattice C is serviceable. It's not mouse-oriented, nor does it support windows, but it does allow the basic text manipulation necessary for program editing in a straightforward way. The Control key handles the more frequently used commands. Other, extended commands, are typed on a command line at the bottom of the screen after pressing the Esc key. The default size of the text buffer is large enough to edit a file of about 60K. A command-line option is available for larger files.
EXTRAS
Unlike the GST and Alcyon compilers, Lattice C includes no assembler. Unlike the Megamax compiler, Lattice C includes no disassembler. It makes no provision for inspecting code generated by the compiler, nor for optimizing it by hand. The calling protocol for assembly routines is clearly documented, as is the protocol for calling a C function from an assembly language module.
Up to eight variables may be declared register variables. The compiler reserves four address registers for pointer variables and four data registers for simple variables. A peculiarity of this compiler is that integers are 32 bits long-the same size as longs. This creates relatively larger and slower code.
The compiler, linker, editor, and other necessary files take up about 293K of disk space. If you're using one single-sided drive, this doesn't leave much room for source. At least one double-sided drive or two single-sided drives are necessary to use this compiler effectively.
SUPPORT
Metacomco a British company, supplies an address in Scotts Valley, California for customer support, as well as their home address in Bristol, England. We at first suspected the California address would be essentially a marketing center, but were surprised to find real technical assistance at the other end of the phone line.
CONCLUSION
Lattice C represents an excellent value for the price. The mature compiler
and its compatibility with the foremost MSDOS compiler makes it an attractive
package. The documentation is clear and nicely presented. Compared to Alcyon
C, its compile and execution times are very respectable.
ALCYON C
We bought our Atari STs with the intention of developing and selling software. At the time, the only software tools available were bundled in the Developer's Toolkit, available from Atari for $300. Although there are now alternate choices, the bona fide software developer who intends to bring a product to market will find the developer's package indispensible. The tools aren't the best, and the documentation leaves a lot to be desired, but they suffice to get the job done. Plus, Atari wants you to succeed in your product development; quite often they are able to assist you with your marketing efforts.
DOCUMENTATION
The developers package includes a compiler and assembler from Alcyon; a linker, debugger, and various utilities from Digital Research, Inc. (DRI); and an editor, telecommunications package (Kermit), and other utilities from Atari. The documentation consists of a six-inch-plus stack of over 2,000 double-sided loose sheets. The principal parts of the documentation are a several-hundred-page GEM Programmer's Guide, a "Hitchhiker's Guide to the BIOS," the "Long-Awaited Line 'A' Document," a GEMDOS manual, and CP/M68K documentation for the compiler, linker, debugger and utilities. The CP/M68K documentation is indexed and includes extensive tables of contents, but it also contains much that pertains only to the CP/M68K environment and must be disregarded. In short, the information is (probably) all there, but there's a lot of chaff with the wheat, and you'll find yourself doing a lot of sifting.
The package includes sample programs plus two excellent examples that help answer many GEM-related questions. ACCSKEL.C and APPSKEL.C are, respectively skeletons for desk accessories and for GEM applications. Add your code and you're on your way The hard part of hooking up with GEM is done for you.
It's been our experience that working with new equipment means using Xeroxed, poorly-organized documentation, tools that don't work well together, and having to figure out a lot of things on your own. That certainly is the case with the developer's package. It was perhaps justifiable a year and a half ago but, unfortunately it is still true today. It is time we start to see typeset, indexed, organized documentation, and tools with more polish than is currently being offered by Alcyon, DRI and Atari.
USE
The Alcyon compiler consists of four pieces: cp68, the preprocessor; c068, the parser; c168, the code generator; and as68, the assembler. A batch-file utility invokes these components.
Alcyon supports many of the same compile-time options that the Lattice compiler does. -dsymbol, and -idir work the same way. -e specifies the use of IEEE floating point format. This supports single and double-precision floating point. -f specifies Motorola's "Fast Floating Point" format which supports only single precision.
The Developer's Toolkit provides an alternate environment for program development. If your tastes run more to traditional shells, you may prefer COMMAND.TOS to GEM. Invoke it, and you will see a bare {a} prompt. The commands are not documented, but if you are familiar with UNIX and MS-DOS, they are what you would expect. We use COMMAND.TOS frequently with the Developers Toolkit. Constantly growing and shrinking windows can become obnoxious after a while, and dialog-box command lines seem to be a clumsy way to start up a compiler.
Two additional tools are unique to this compiler and are invaluable. nm68 is a utility similar to the UNIX nm. It takes a ".O" file as its input and prints its symbol table. This is handy for resolving undefined function errors during link. Another unique facility is SID, which stands for Symbolic Interactive Debugger. It is an assembly-level debugger that supports basic operations such as single-stepping, disassembling, examining and changing registers or memory, and setting breakpoints. It doesn't have a mini-assembler built in, and it's not symbolic, but it can be very useful at times.
The Alcyon compiler supports two of the five ANSI language extensions previously mentioned. It allows structure assignments and the use of "unsigned" as a type modifier It parses function prototypes, but makes no use of them for type-checking.
Alcyon C allows a maximum of eight register variables. Three registers are available for pointer variables and five for other register variables.
EDITOR
The editor supplied with the Alcyon package is called Micro EMACS. If you've used the full EMACS on a large machine you know that it is an endless source of delight. It's fully customizable, extensible, and comes with an enormous amount of on-line help and documentation. Of this, Micro EMACS retains a minimal, non-customizable, non-extensible subset. It's not a bad editor; its major fault is the lack of a search and replace function. A minor fault is the awkward Esc-V key sequence used to page through the text. On the positive side, Micro EMACS can edit text in several (non-GEM) windows, but it doesn't support the use of the mouse. An informal survey found that most of those who spend the majority of their time editing vs. word processing, preferred to use the Micro EMACS editor.
The minimal working set of compiler, linker, batch utility editor, and. necessary libraries for Alcyon C comes to 455K of disk space. By splitting compiler and linker files and juggling disks, it is possible to work on small programs using Alcyon with one single-sided drive, but not really practical. Indeed, the lengthy compile and link times for this package make any floppy-based system almost unbearable. The only real alternatives are a large RAMdisk, or a hard disk.
SUPPORT
To really take advantage of Atari's support with this package, you will need a modem and a CompuServe account. Atari maintains a CompuServe SIG dedicated to registered developers. Here you'll find frequent bulletins with the most-asked questions and their answers, announcements, copious source code to study additional tools and utilities, and direct access to Atari's technical and marketing support.
CONCLUSION
There's a lot to love and a lot to hate about this package. The support
is unparalleled. The documentation has more information than is available
from any other single source. And there are more tools and utilities that
come with this compiler than with any other. On the other hand, the documentation
is poorly organized and contains significant amounts of irrelevant and
erroneous material. Also, the compiler and linker are by far the slowest
of the four reviewed. The principle advantage to Alcyon C and the Developer's
Toolkit is its support.
MEGAMAX C
Megamax is hoping to lure software developers away from DRI and the Alcyon package. With this intent, they are offering most of the features that the Alcyon development package has, plus some nice extras. The heart of the Megamax package is a one-pass compiler. If you are as tired of working in a batch mode with your C compiler as we were, then you will really enjoy working with a one-pass compiler. Compiles that took ten or fifteen minutes now compile in one or two. Megamax claims that it compiles ten times as fast as the Alcyon compiler. With smaller programs, we have noticed about a five to one ratio. When compiling DOODLE, the difference was incredible!
DOCUMENTATION
After wading through 4,000 pages of developer's documentation, or looking up brief, inadequate GEMDOS function descriptions, the Megamax documentation is a joy to behold. It is clearly written, and typeset by laser printer. Each function call is on a page by itself and the user is almost never sent thumbing through to the manual to find explanations. Generally where the information could reasonably be reproduced, it was inserted where it was needed-even if this meant copying sections of the manual verbatim. They do have a small problem with the VDI section: All the function calls in the index are off by one page. But they are there! They have even reprinted all of the ".H" files for easy reference.
An important consideration for any professional ST developer is the quality of the GEM hooks. We could find no GEM hooks, BIOS or XBIOS calls that Megamax did not support. Just as important, they have thoroughly and clearly documented them. The package includes over 300 pages of documentation with only one function per page. The table of contents is accurate and the index is a sight for sore eyes. Without question, the documentation is the best available to an ST software developer.
USE
The Megamax shell places you in an environment very similar in look and feel to the GEM Desktop. Several drop-down menus give you the ability to compile, link, execute, change libraries etc. Thus, without leaving the shell, you can take a program from source code to execution.
In conjuction with the shell, Megamax has created their own dialog boxes which offer some nice features unavailable with standard GEM boxes. Megamax's boxes provide considerably more information and you can scroll through an entire directory by holding down the mouse button on the scroll arrows. To avoid cluttering your screen, the dialog box only displays the applicable files. For example, while in the compiler, only the ".C" files are displayed. Unfortunately while the shell remembers what disk drive you are using, it doesn't remember what directory you are in. This means that anytime you need to compile or edit, you have to walk the program down from the root directory. The path length that you are able to type in is somewhat limited as well. A hard disk makes these limitations particularly annoying. But, overall, the shell is quite convenient to work with.
A feature of the Megamax compiler some developers may feel is a disadvantage is that it does not and cannot directly produce assembly source code. This speeds up the overall compile process tremendously. But, if you like to develop in C, then manually optimize the intermediate assembly source code, it can be quite involved. A disassembler is included, so compiling your code, then disassembling it is possible. But this whole process is annoying.
Megamax produces "pure," relocatable code, which means it separates the data and program code. Because they are separate, if you exceed the bounds in an array reference, you destroy data, but you don't destroy the program itself. However, this introduces the major drawback of the Megamax compiler: no single execution program segment can be over 32 kilobytes in size. This limits any given function to less than 32 kilobytes and requires that the programmer add compiler directives in the source code, telling it to break up the code into appropriate-sized blocks. The linker then resolves addressing problems between overlays by means of jump tables. Megamax is considering using this as a memory-management and overlay scheme at some future date. However, at this time, the entire program loads into memory. Except for adding the compiler directives to the source code, this whole process is completely transparent to the developer and the user.
While this is a holdover from the compiler Megamax developed on the Macintosh, it has some advantages. The first is that, within any given segment, the execution times are much better. It also means that if Atari comes out with a multi-tasking operating system, memory management is already built into the code. Since Atari is a UNIX licensee, this is something to keep in mind. The code is generated almost exclusively with PC relative addressing which reduces code size and increases code speed.
One of the nicest features of this compiler is the error log. If you
have a program which takes forever to compile, you can get up and stretch
your legs. Should an error occur, the compiler will save it to a file.
When you get back, just check for the presence of an error file. We do
have a quibble with this feature: If you have an error file left from a
previous compile, an error-free compile will leave it intact. It would
be less confusing if a clean compile erased the old file.
can be
used on one
single-sided disk
drive.
The linker is an intelligent linker; it only loads the external symbols and functions it needs, thus reducing code size. Because the 68000 has special addressing commands that take advantage of nearby addresses, the smaller code size can mean faster execution speed. When the linker scans for either a function or a symbol, it stops at the first incidence of the definition. Since the system library is loaded last, the user can redefine parts of a library and still access other parts of the same library.
The Megamax linker is the slowest program of the package. To use the linker from the shell, you single-click the files that you want to link, then add them to the link-list window. Once you have added all the files you want linked, click the OK button and Megamax loads and links the program. The system library is automatically searched and is not even listed when the program asks what you wish to link. Therefore, unless you create additional libraries with the "librarian," you only need to explicitly link one file.
The librarian referred to above is an interesting additional feature. One of its principle functions is to facilitate modular compilation. Once you have a module debugged, you compile it and put it into a library module. Then you just link the library module with the development module at link time. Since the librarian resolves all local references, this not only reduces the amount of code requiring recompilation, but speeds up the linker. It also reduces the size of the library module.
Megamax can effectively be used on one single-sided disk drive: a nice, money-saving feature. The basic compiler, linker, librarian, system library, shell, some sample source code, etc., use less than one single-sided disk. Thus it takes up minimal storage on a hard disk, and the whole program will fit nicely onto a RAMdisk. Unhappily portions of the Megamax files must remain on the top-level root directory, so you cannot place the whole system within a folder This is inconvenient for hard disk owners. With a RAMdisk, the edit, compile, link and execute cycle is measured in seconds. Even with the standard single-sided disk drive and 512K of RAM in a minimal 520 ST systern, the program performs elegantly.
Another particularly nice feature is that Megamax can handle, compile, and link a source file which is in a different disk drive than the compiler, linker and header files, without requiring any special contortions on the part of the programmer. Just single-click the disk drive you want to use and the shell lists all the applicable files on that disk. If you want to use them, activate them with a single-click, then click the OK button. If you are compiling, the compiler will produce a ".O" file on the same disk as the source code. If you are linking, by default, the program will produce an A.PRG file on the same disk as the system. You can redirect it to a different disk or file name if you like. Unfortunately it will not do multiple compiles or links. Nor will it compile and link in one command.
Megamax has abided by the Kernighan & Ritchie standards and added several extensions from the new ANSI standard. These include structure passing, structure assignment, and functions returning structures. The same member name can be included in more than one structure, and character constants can be both integers and longs. To allow programs larger than 32K, they also added the overlay mechanism mentioned previously.
EDITOR
The Megamax editor is a mouse-based editor that includes complementary keystrokes for the drop-down menus. Nonstandard use of the arrow keys was the worst problem that we encountered; the cursor keys move the window instead of the cursor. Only the mouse moves the cursor. Another major failing: It can't handle files greater then 32K. While this editor may be a little better than some of the keyboard-based editors available, it is quite poor and difficult to use. Along with the 32K compiler limitation, the editor is a weak point in the Megamax package. We do not feel that it is adequate for a professional environment and, in fact, do not use it. We have found the GST editor to work very well within the Megamax shell. For that matter, 1ST Word, which is free, will also work very well with the Megamax system.
EXTRAS
The Megamax package comes with several unusual additions, including:
a code optimizer, a full resource construction set, a disassembler, a "make"
utility Megaroids (the arcade game bundled with the ST, written in Megamax
C), and a set of example programs Some of the
uses the GEM
environment better
than any of the
other
packages.
example programs demonstrate writing directly to screen memory, how to format a floppy disk from within a program, use of in-line assembly, creating application skeletons and accessory skeletons, and how to create a dialog box. Additionally the source code for the support libraries is available for $50. This includes both disk and printed hard copy. A hard copy of Megaroids is available for $25.
SUPPORT
We have called upon Megamax for technical assistance a number of times and invariably have found that the Megamax technicians not only knew their own compiler, but understood GEM! Having first written a C compiler for the Macintosh, they have some unique insights to the strengths and weaknesses of both systems and are a valuable asset to any programmer. Megamax has one full-time person dedicated solely to supporting their compilers. This may be contrasted with companies who rely on their compiler developers to also substitute as support. Megamax does not have toll-free phone number, but they do publish their phone number where it is plainly visible and usable. Since the first copy of the compiler that we received was a pre-release version, we called them a number of times. Without exception, they were very helpful.
Megamax has a reasonable upgrade policy. For $20.00 they will send you the latest version of the program and any necessary documentation.
CONCLUSION
At two hundred dollars, Megamax has priced their compiler beyond the
casual programmer. But the serious developer will have a hard time finding
a better C system. Megamax has concentrated on those areas where the Alcyon
compiler is weakest, i.e., its interface, speed of execution and documentation.
They have produced a very nice package. Admittedly, some will find the
32K program limit a major flaw in this package. But we have worked considerably
with other C compilers on both minis and micros, and the only thing we
miss with the Megamax compiler is a sourcelevel debugger and a decent editor.
It is a good, solid package that any programmer can use and enjoy.
GST
We had a good first impression of GST's C package. Its interface is smooth and the editor very similiar to 1ST Word, the word processor that comes bundled with the ST. Unfortunately, we soon felt very restricted and frustrated. This product is a very good prototype of a professional package. Unfortunately, at the time of this writing, it is too unfinished to be a serious contender for the professional developer.
Currently it does not support some of the fundamental constructions of C. This is particularly limiting since many GEM calls require the address of a structure as a parameter. This doesn't mean that productive and professional products can't be produced with this package. In fact, according to their documentation, the compiler itself and all the other products from GST, including 1ST Word, were written either with this compiler or their macro assembler. However; in addition to problems with the language implementation, the GEM documentation accompanying GST C is not sufficient to produce a product ready for market. They refer you to the GEM manuals from the Developer's Toolkit. As previously mentioned, GST shouldn't be expected to reproduce the information on GEM, but compared to the other packages, the amount of GEM documentation is extremely limited.
DOCUMENTATION
The GST documentation leaves quite a bit to be desired. Their explanation of the various menu items in the shell is fairly thorough, but they fail to explain all of them clearly. It has no index, but the table of contents is quite good and it has a function summary showing the parameters that each function needs. Unlike most of the other systems, GST gives a brief explanation of each of the language constructions they have implemented to date. This serves to document the features of their implementation and it introduces the beginning programmer to the C language.
The accompanying system libraries are a reflection of the entire GST language implementation: an interesting combination of possibilities and missed opportunities. GST C has a nice standard C library and it is well supplemented. However, only a few UNIX-standard calls have been implemented. It is missing several low-level UNIX calls such as "open" and "close". In spite of not having these calls available, the file I/O is surprisingly quick. Since casts, structures, floating point and noninteger functions are not available with GST, there was no way to compile DOODLE, and we had to rewrite the benchmarks. The timer routines available with GST were only accurate and precise to within two seconds, which made several of the benchmark times meaningless.
Offsetting a rather strange standard library is a delightful supplemental GEM library that removes much of the tedium from the GEM interface by doing some of the housekeeping for you. As part of this approach, your program is automatically placed in a window. It is pretty startling the first time you write a "hello world" program and see it come up in a window with borders, scroll bars and the rest of the window niceties. GST's version of windowing calls are quite a bit easier to work with than the normal GEM calls. If portability is not a concern, this is a very nice feature. Depending on your application, you may not need or want the low-level routines that were not implemented. This library could justify using GST if your primary concern is developing a quick prototype and you do not want to spend a lot of time fighting with GEM.
USE
One of the reasons GST's limitations are so frustrating is that the
user interface and editor in this package are among the best available
for the ST. In many ways the GST shell uses the GEM environment better
than any of the other packages. It is well designed and intuitive. You
can compile, assemble and link a program from a single drop-down menu.
If you have already compiled, you can just assemble and link. You may also
link an assembled file. The program keeps a log of your activities so that
if you are not paying attention during a compile or program execution,
it tells you the results. It is a very well-done interface.
wants you to succeed
in your product
development.
GST uses a one-pass compiler that works reasonably quickly The syntax for handling in-line assembly is a little different than the other compilers, hut it is not excessively cumbersome.
The compiler has an option to pause on locating an error condition. However, for some reason, when we used this, it seemed to hang for a while, then go on randomly after several presses of the Return key. One useful command option is the ability to have your comments from your C source code preserved and passed on to the assembler code.
The GST assembler is a very quick two-pass assembler. You have the option of producing either relocatable or nonrelocatable code. It is intelligent enough to spot long branching instructions that could be replaced with short branches and it warns you about them.
The GST linker is the same one used by Lattice C. It can be instructed to either include an entire library or import only those routines required for linkage. In tight programming environments, this lets you optimize code size. The linker requires a command file to produce its output. The command file tells the linker what files to link and which libraries to search or include. According to drop-down menu options, the output and error messages of the compiler, assembler and linker can be re-routed to a file, a list, the console, or an auxilary device. Unfortunately, this feature and the command file for the linker are not well documented and we couldn't get the redirection to work properly.
A real problem we ran into was the size of the intermediate code. With two double-sided disks-one for the system and one for the source code-we often had to stop and delete files from the disk. On any given compile, five files are produced and retained. This situation makes a single-sided, single-density disk system useless for any significant development.
EDITOR
The GST editor is the highlight of the package. It is GEM based and very similar to 1ST Word. If you are switching back and forth between word processing and program editing, this saves the necessity of readapting to a different interface each time. The function keys have been redefined to suit actions appropriate to a programming environment-such as "move to the end of the line," etc. Like 1ST Word, the function-key boxes are drawn at the bottom of the screen and the programmer has the choice of keyboard input or mouse input. The editor is slow to respond, so it is easy to "get ahead of it" while using the cursor keys.
The ability to go to a specific line number is an important feature this editor lacks. GST avoids the necessity of line numbers by listing each function as it is compiled. It then lists the offending line. Usually this is enough to get you in the appropriate area of code if you are using the GST compiler with the -m option. Another missing feature is continously scrolling scroll arrows. GST has implemented the continuous scroll arrows in the dialog boxes, but for some reason they didn't use them in the editor itself.
In spite of these problems, this is the editor we use with large-scale code. It is easy to use and handles extra-large files easily and without problems. With just a little bit of clean up it would be worth the purchase price of the package alone.
SUPPORT
Antic Publishing Inc. is supporting this product. They offer bug fixes free and upgrades at a nominal charge. As of June 1986, GST is planning a toll-free 800 number for technical assistance.
CONCLUSION
Those features of GST which have been implemented, have been implemented very well. The shell and editor use the GEM environment better than any package currently available. The fundamental difficulty of the GST C package is the features which were not implemented. As it stands, GST C is reminiscent of Small C from Dr Dobbs. Because of its low price, we would like to be able to recommend it to beginning programmers. But without structures and other essentials of the C language, we are unable to do so. The tricks, and techniques that this package would force one to use might create bad programming habits. However, GST C has the potential to be a real winner if the company chooses to finish it. They are trying to do that as fast as they can. We look forward to seeing the finished product.
SUMMARY
Each of the development packages mentioned has certain advantages. If you are a software development house, or have a program ready to market, strongly consider the Developer's Toolkit with its CompuServe connection and marketing support. For a development compiler, Megamax C is, without question, the best available on the Atari. It will reduce your compile/test turn-around time by at least a factor of five. By taking advantage of the make utility and code modulation, this factor can increase to as much as ten. Unfortunately, at $200, it is a bit expensive for many people. With many students, and hobbyists, price is the single most important factor. The Lattice compiler, at $50 less, does not really offer a significant savings. However, its compatibility with its IBM cousin is a real plus. On the IBM PC, the same compiler, without an editor, has a list price of over $400. On the lower end, the GST package comes in with a very nice shell at half the price of the Lattice package. Depending upon how quickly GST upgrades it, this package is one to keep an eye on.
REFERENCE:
- COMPUTER LANGUAGE Magazine, 131 Townsend Street, San Francisco, CA 94107, (415) 957-9353
LIST OF MANUFACTURERS
Alcyon C (Developer's Toolkit)
Atari Corp., 1196 Borregas Avenue,
Sunnyvale, CA 94086, (408)745-2000
$300
CIRCLE 204 ON READER SERVICE CARD
Megamax C
Megamax, Box 851521,
Richardson, TX 75085,
(214) 987-4931
$199.95
CIRCLE 205 ON READER SERVICE CARD
Metacomco's lattice C
The Catalog, 524 Second Street,
San Francisco, CA 94107,
(800) 443-0100 Ext. 133
$149.95
CIRCLE 206 ON READER SERVICE CARD
GST C
The Catalog, 524 Second Street,
San Francisco, CA 94107,
(800) 443-0100 Ext. 133
$79.95
CIRCLE 207 ON READER SERVICE CARD
ATARI ST C COMPILERS
| ALCYON | MEGAMAX | LATTICE | GST | |
| Price | $300 | $200 | $150 | $80 |
| Full K&R | yes | yes | yes | no |
| Number of Registers | 8 | 6 | 8 | 0 |
| Integer size | 16 | 16 | 32 | 32 |
| * Minimum disk size | 711K | 325K | 538K | 398K |
| ** Minimum drives | 2 | 1 | 2 | 2 |
| GEM doc. | yes | yes | partial | list |
| Index | partial | yes | yes | no |
| ANSI extensions | partial | partial | full | no |
| GEM shell | no | yes | +yes | yes |
**Minimum single-sided drives for 'practical' usage.
+ AS of June 1986, Lattice is shipped with a GEM shell.
BENCHMARKS
| DOODLE: | ALCYON | MEGAMAX | LATTICE | GST |
| Floppy compile | 17:50 | 1:28 | 8:36 | N/A |
| Floppy link | 5:45 | 1:41 | 6:55 | N/A |
| Hard disk compile | 6:27 | :40 | 5:15 | N/A |
| Hard disk link | 2:16 | :48 | 2:10 | N/A |
| End code size | 16,705 | 15,854 | 36,154 | N/A |
| DHAMPSTONE: | ALCYON | MEGAMAX | LATTICE | GST |
| Floppy compile | 5:08 | 0:30 | 2:29 | 1:27 |
| Floppy link | 3:21 | 1:44 | 4:34 | 2:44 |
| Hard disk compile | 1:56 | :12 | :48 | :45 |
| Hard disk link | 1:38 | :26 | 1:22 | :38 |
| End code size | 18,154 | 11,075 | 19,000 | 25,625 |
| DHAMPSTONE TIMES:(in seconds) |
ALCYON | MEGAMAX | LATTICE | GST |
| Strings | 7.87 | 7.60 | 7.57 | 10 |
| Integers | 2.03 | 2.05 | 3.11 | 4 |
| Longs | .27 | .25 | .38 | 2 |
| Unsinged | 1.65 | 1.85 | 2.00 | 2 |
| Double | .120 | .72 | .10 | N/A |
| * Disk I/O | 35.70 | 9.67 | 20.07 | 16 |