MARK WILLIAMS C & MENU +
BY ARICK ANDERS
Last issue, START published its first comparison of ST C compilers. No sooner did the issue go to press, than another major candidate entered the marketplace: Mark Williams C. How does this new contender measure up? Read on.
The world of microcomputers is a hectic world at best. New products come out suddenly, announced products never appear, and old products emerge anew with major revisions. In the short time since START reviewed the available C compilers, Mark Williams, a company with an established reputation in the minicomputer world, bas adapted its C compiler package for the Atari ST.
The Mark Williams package is different from the previously reviewed compiler packages for a variety of reasons. It is significantly more sophisticated, with the accompanying benefits and drawbacks of that sophistication. Experienced UNIX gurus will appreciate its UNIX-like shell and utilities, while those less familiar may find it cryptic and harsh. The compiler and linker are full-blown C implementations with options straight off a minicomputer. It also has an assembly-level symbolic debugger, a true MAKE utility, the Micro EMACS editor and the source code for the Micro EMACS editor.
The documentation for the Mark Williams package is extensive but contains several omissions and many errors. It actually consists of three manuals bound together: 512 pages are devoted to the overall package, with 25 pages for a MAKE utility and 77 pages going to the Micro EMACS editor. Even without GEM AES/VDI information, the manual is over 600 pages long. Like the Lattice C documentation from Metacomco, this manual is paperback. However, it has a high-quality binding that will withstand normal treatment. (I found that the Lattice C binding was of poor quality and fell apart quickly under normal use.)
Mark Williams has tried a new approach in ST C documentation by putting most of the reference information in the alphabetical format of a lexicon. This portion of the manual occupies 367 pages and is, for the most part, extremely easy to use. Unfortunately, it was in the lexicon I found most of the errors in the documentation. For example, they have omitted some of the implemented BIOS and XBIOS calls, and many of the "types" listed in the function descriptions are erroneous. Structure pointers were often mistakenly referred to as character pointers, and vector addresses were referred to as longs instead of function pointers. More seriously, some of the commands, such as floppy disk commands, listed parameters as char type, when they are, in fact, longs. This type of mistake can wreak havoc with your stack and prove extremely difficult to locate.
Fortunately, while Mark Williams needs to concentrate more on their editing, they have some very good programmers! Laced throughout the lexicon are pages and pages of example programs that demonstrate the various library, BIOS, XBIOS and GEMDOS functions and how to use them. The examples are well written, well commented and show solutions to real world problems.
I was annoyed, however, by the occasional failure to reproduce in the lexicon information appearing in the tutorial sections of the manual. For example, the "history" command is not discussed in the lexicon-at least I was never able to find it. However, it is found in the table of contents and in the index. Each section of the manual has its own table of contents and index and both are excellent. I never found myself saying "I remember reading that, but I can't find where."
The section on the MAKE utility, which is written in an almost tutorial format, is clear and most programmers will find it sufficient to allow them to use the utility. A handy example included in the tutorial is the MAKE file for recompiling the Micro EMACS editor from the source code that comes with the package. One problem with the MAKE utility was that the colon in a device specifier, such as "B:\," confuses it. Consequently, you are unable to use device specifiers.
The section of the manual on the Micro EMACS editor is adequate, but the command summary is listed alphabetically. This is a handy format if you want to locate what a particular command does, but it is a pain to work with when you want to find how to skip to the end of the page, or how to do a search and replace.
A real void in the manual is the complete lack of any GEM
to micros, Mark Williams has
established a strong
documentation. Scott Herm, of Mark Williams technical support, suggested they may come out with GEM documentation in the future. As mentioned in the last issue of START, the real blame for insufficient GEM information lies at Atari's feet. Nevertheless, this is no excuse for completely ignoring GEM since it is a significant part of the machine and many languages cover it in some degree.
Most of the problems with Mark Williams' documentation are due to careless editing. It is not uncommon to have two successive sentences repeat the same thought almost verbatim, and information in a function description often fails to match the accompanying example program. However, the actual writing is usually very readable. The material is arranged logically and the lexicon style smoothly bridges the gaps between the novice user and the experienced programmer.
Prior to using the compiler you need to install the product on either a hard disk or a couple of double-sided disks. This is a painless operation, with the computer doing most of the work, but it is time consuming.
(Editor's Note: At press time, Barry Bowen of the Mark Williams Company assured us that they were shipping version 1.1, which includes an improved manual and an automated install procedure for common system configurations. He also noted that Mark Williams will deliver compiler packages with single-sided diskettes upon request and at no additional charge. START did not receive version 1.1, and we were, therefore, unable to verify these claims.)
The standard set up, with a double-sided disk, leaves you with a compiler disk and a commands disk. After using the compiler disk for a while I copied the date program over to it from the commands disk. Then I moved the shell program to an AUTO folder and expanded the PATH environmental variable to look in the AUTO folder. This meant I could now boot from the compiler disk keeping my source disk in the B: drive.
After either booting off the above disk, or double-clicking the shell program, you find yourself in a mini UNIX-like environment. The default prompt is a dollar sign. From there you can do a number of things such as change default disks, sort a file, get the difference between two files, get a character/word/ line count on a file, compile, link, set the date, run a GEM application, run a TOS application, dump a file in any one of five formats, list a directory or even do a file move. The move
and linker are
full-blown C implementations
with options straight off
is handy if you don't have room on a disk to copy and delete a file. It just changes the directory pointers around. On a cross-device transfer, it copies the file and removes it from the original device.
A handy feature is the ability to use batch files containing any of the shell functions or any executable program that is in one of the directories listed in the PATH environmental variable. Another is the ability to redirect input or output to or from alternate devices/files.
There are three ways to compile a program. You can compile a number of files in one command from the shell program, you can include a compile command in a batch file, or you can use the included MAKE utility. Unlike the Megamax MAKE, which is more of a time-dependent batch compile and link, the Mark Williams utility is a full-blown MAKE with file dependencies specified, including the header file dependencies. As mentioned, the MAKE utility can't handle different devices, but in spite of this, most serious developers will want to use this utility.
The Mark Williams compiler itself is a true minicomputer compiler with so many options you won't remember them all-much less use them. (For example, the -M option will allow you to use alternate programs for the different passes in the compiler.) The compile and link times are comparable to the other traditional multiple-pass compilers, though the times were nowhere near the speed of the Megamax package. (Editor's note: See Figure 1-3 for test results. These charts test the same features as last issue's survey. For purposes of this article, we have also published the results of Alcyon C,from the Atari Developer's Toolkit. See last issue's chart for comparison with Megamax C, Lattice C, and GST C. ) Like the Megamax package, Mark Williams offers a disassembler to generate assembly-language code for hand optimization or code inspection. It is enabled via a command-line option on the normal compile command.
The compiler is very strict, combining the normal compile responsibilities with many of the warnings of LINT It in-
utility can't handle
different devices, but. . . most
serious developers will
want to use it
cludes options to compile with either strict Kernighan and Ritchie, or Berkeley rules. Nested comments are permitted. Unused registers or variables can be noted if the correct flags are set. A command-line argument can be used to keep the compiler from linking. The compiler will recognize an object file by its ".o" extension and only link it in with the final pass. The linker is the final pass of the compiler and it is much easier to pass the compile command a ".o" file than to mess directly with the linker itself. To compile AES/VDI programs, you add a -VGEM option on the command line.
The compiler implements some of the new ANSI standards, including unsigned modifiers, passing, assigning and returning structures, enum types and the void type. However, it does not implement function prototyping. The integer is 16 bits. There are eight registers available, three for addressing and five for data.
The accompaning libraries are the most extensive available on the Atari ST at this time. Among the routines that it includes are three type of sorts, an extensive math library, a random number generator that works, plus the usual UNIX, AES and VDI calls, and C-level access to the Line A calls.
The Micro EMACS editor is a traditional keyboard editor. It is RAM based, meaning it uses any available memory. I tried to use it to write this article, but the word wrap is very kludgy and not particularly useful. However, for editing programs, I felt that it was easier to use than other editors I have tried. It has macro capability, as well as search and replace. The absolute GOTO command means it can be used with a number of compilers that generate line numbers with their errors. You are able to open a number of horizontal, non-GEM windows in the editor which split the screen into two or more windows of one or more files. There is unlimited retrieval from the "kill" buffer, so data can be moved between files easily.
If you don't like a particular feature of the editor, you can change it. Mark Williams includes the source code and the MAKE file for you to rebuild the program yourself. This is a fun little addition that I suspect many programmers will enjoy.
The Mark Williams package is quite usable on a double-sided, two disk-drive system. By the time you read this, the system will also be available on single-sided disks. But, with the amount of disk space the program and commands use, this is not a practical package for any hardware system with less than one double-sided disk drive and an additional single-sided drive. All told, the minimum disk usage is over one megabyte. If you want to play around with the accompanying source code, you will either need to use a lot of disks, or have a hard-disk drive.
I was not impressed with the support I received from the Mark Williams company. I called several times and the person I talked with regularly had to ask someone else for the answer to my questions. Most of my phone time was spent waiting for them to track down the answer. Since support is only available during Central Daylight Time business hours, this can get expensive.
Mark Williams offers a very nice package. The format and organization of its documentation is fantastic. It is unfortunate that it is marred by poor editing. The writing is well done, reasonably clear and the table of contents and index are unsurpassed. Lack of GEM documentation and a resource construction set is a definite drawback if you are planning on developing just for the Atari. However, with a solid compiler running on systems ranging from VAX to IBM PC, Mark Williams C on the Atari ST offers the professional developer a convenient migration path to a variety of machines at a very reasonable price.
Mark Williams C
Mark Williams Company
1430 W. Wrightwood
Chicago, IL 60614
|In last issue's C compiler comparison review,
we noted that the Lattice C compiler package had neither a command interpreter,
nor a GEM shell. This meant you had to take your hands off the keyboard
to double-click the mouse, then type a whole list of command-line options
when the Tos-Takes-Parameters dialogue box came up. The net effect was
to combine the worst elements of both interfaces.
Since that article, Metacomco has solved these problems with a new program called Menu+, now being released with all of their language products-including Lattice C. Menu+ combines the intuitive, easy-to-use GEM interface with the convenience of a "history" command, normally found only in traditional command interpreters such as the UNIX C-shell. A history command is an instruction that tells the computer to repeat one or more previously entered commands. If you have programs that rake a lot of parameters on the command line, as does the Lattice C compiler, and you often repeat the same command sequence, a history command can save a lot of keystrokes.
Menu+ places you in a GEM shell with four menu choices across the top of the screen. In the center of the display is a window with the normal movement and scroll bars. The window will display the last 50 commands you executed since you booted the Menu+ program. To repeat a particular command, you double-click it. Simple. When the command has finished execution, you will be returned to the GEM shell with the last command added to the list. If you consider how many times a developer goes through the "edit, compile, link, test run" cycle, the advantage of this feature becomes obvious.
The four menu choices at the top of the screen are Desk, File. Tools, and Options. Desk contains the usual desk accessories and File is how you specify the default disk directory and the working file. Under Tools are listed the programming executables that you normally work with: editor, compiler, linker, and others. The last menu choice, Options, offers options for the various programs you might want to use, such as "Editor_opts" or 'Linker__ opts." For example, if you want the GST linker to append a symbol table onto the binary file for debugging purposes, the menu item for Linker opts would be set to -DEBUG. Then, whenever you ran the linker from the "Tools" menu, the option for debugging would automatically be appended onto the command.
Handy though this is, what really makes this program useful is that the user can modify the last three menu-choice displays and define what they do. Thus, you can define a menu option for whatever language, compiler, utility, or game you want to use, then run it from the shell. Commands can also be combined so that one menu item will execute any series of commands you need. When commands are combined in this way, you can set the sequence to pause, or to continue immediately with the next command. Since linking isn't particularly' useful alter a faulty compile, the sequence can be set to return to the shell when an error is detected.
Customizing the menus is straightforward. The documentation is a different story. Not only did I find the style confusing, but there is no table of contents or index. Fortunately, it is short (only twenty-six pages) with lots of pictures, and the section headings are in bold print; it is possible to find what you are looking for by flipping through the manual.
Accompanying the program is a utility that will display,. print, delete, copy or rename a file. Menu+ also includes five example data files that can be used with the language packages from Metacomco.
While Menu+ can be purchased with the Metacomco editor for $29.95, it is also being shipped with their five language packages: MCC Pascal, MCC Assembler, Lattice C, BCPL, and Lisp.
Menu+ won't be much help to you if your program causes the computer to crash and you have to reboot regularly. It also won't be of much use if you rarely repeat a command sequence. However, if you use the same basic command sequence often, you may' find it a very worthwhile utility. Those of yon who receive Menu+ bundled with a language package are getting an extra bonus.