WHICH C FOR ME?
  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.
                            _________________

                                  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

  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

  * Dhampstone creates a test file of 12,987 bytes by assigning a short
  string buffer and writting it to disk 1,000 times, one byte at a time.