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.
_________________
Among
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.
_________________
We were
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.
_________________
Megamax
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
_________________
The GST shell
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.
_________________
Atari
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
* Disk usage includes editors and all library and link files.
**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
