MARK WILLIAMS C 2.0
The most complete development system for the ST now works with floppy-based systems, too!
by Arick Anderson
Mark Williams Company has released a new version of the Mark Williams C compiler for the Atari ST. Version 2.0 adds some very nice features to a solid, mature package. The company seems to have examined those areas where previous versions were weak and listened to suggestions from customers.
The biggest improvement for many buyers is that the compiler can be used on a floppy disk-based system. You can now compile small to medium-sized programs with only one drive and a RAMdisk (though with single-sided drives it's a cumbersome process--I would recommend two drives). A hard drive is still optimal, but it is no longer absolutely required.
The package includes an Install program that will have anyone--novice, student or developer--up and running with minimal problems. The Install program asks you what your environment is and then builds either the disks or directories you need; all you do is swap disks periodically. If you are using single-sided disks, you can copy the compiler and utilities directly off the distribution disks.
I originally chose Mark Williams C rather reluctantly. It wasn't the fastest compiler available; the compile times were significandy slower than the competition. In fact, I used to run my previous compiler from within the Mark Williams shell just so I could use the environment and utilities without sacrificing speed. I liked the Mark Williams compiler's error checking, which can be set to different sensitivities. A real Unix-style "make" utility was also a plus.
Version 2.0 goes after this from two directions. First, it compiles about 25 percent faster than version 1.0. To speed things up even more, version 2.0 includes a RAMdisk program that survives resets and most crashes. Using the RAMdisk for temporary files cuts compile times in half, and puts Mark Williams version 2.0 in the same ball park as the fastest compiler currently available for the Atari ST.
The timings in Figure 1 are for the Dhampstone benchmark, a set of routines more fully described in the Fall 1986 START, and for compiling Doodle, the public domain GEM drawing program. All times are in seconds.
One new feature is the -A option on the compiler; if a fatal error causes your compile to halt, you automatically return to your source code in the editor at the location of the first error. A single command moves you to the next error. When you leave the editor you can either return to the shell or resume compiling. This makes the compile/edit/compile cycle a lot smoother.
The editor is a reasonably robust RAM-based version of MicroEMACS, an adequate editor that more or less by default has become my editor of choice on the ST. With this version you can suspend an editing session and temporarily return to the shell, examine files or whatever, then return to your editing session with a simple command. It's not mouse-based, and the keyboard commands are fairly standard, using control keys and escape sequences. As with previous releases, the source code to the editor is included with the package.
For a Unix user, the Mark Williams shell will be familiar. The new version adds some delightful features, including "aliasing," which allows the user to give more familiar names to the rather cryptic operating system commands by changing the profile file (The profile file contains the shell commands that you want executed every time you enter the shell.)
The shell also incorporates "environtmental variables," which let you specify paths for temporary and Include files while compiling (complete with multiple pathways and directories to be searched). There's a command history capability, but it's quite primitive; your previous commands can be re-executed but not edited.
From the shell you can archive, change the cursor, run a symbolic debugger, check free RAM and disk space, run either TOS or GEM programs, manipulate the mouse, add and delete files and directories, show and save screens in any of the major graphic formats, reset an entire directory's file modification dates with a single commend, count the words/lines in a file and a host of other things. In short, the shell has utilities and features that in many packages you would expect to pay extra for. No other compiler package currently available on the ST offers anywhere near the utility support that Mark Williams does.
There is a gap in the utilities, though: the lack of a resource construction set. Mark Williams has one in development, but it probably won't be available until the next release.
Mark Williams made the RAMdisk "permanent" - if you crash your system, you can reboot and retrieve any source code left there. You can also make a bootable image of the RAMdisk so you don't have to reload your RAMdisk each time by hand. The system can also boot off the RAMdisk.
That, at least, is how it's supposed to work. In practice, I have never been able to get the Mark Williams RAMdisk to work. In fairness to Mark Williams, I have an unusual hardware/software environment: a one-meg 520 ST with two double-sided floppies, a Z-Time internal clock chip, the Beckemeyer Hard Disk Cache program and a 20-megabyte Supra hard drive partitioned into drives 'C' through 'K' with drive 'M' drive set aside as a RAMdisk. (The 'C' drive doesn't show up on the desktop--it's set as a system/boot disk.) This is obviously not the ideal environment to try out what appears to be one of the niftier RAMdisk programs available.
I talked with Mark Williams' customer support about the problem, and they gave me a program fix over the phone. Since the source code to the RAMdisk is also included with compiler, recompiling the RAMdisk was easy. Unfortunately, my problems with this RAMdisk program just wouldn't go away. Mark Williams Company knows for sure that the Beckemeyer cache program is incompatible, and the Supra Bootstrap program may also be colliding with the program.
Though other developers reported favorably on the RAMdisk, I simply wasn't able to get it going. However, using the same idea, the TMPDIR environmental variable, and a public domain RAMdisk, I was able to perform the benchmarks for this article.FIGURE 1
DOCUMENTATION AND SUPPORT
The documentation for earlier versions of the Mark Williams compiler was innovative, but it had some significant shortcomings: AES/VDI documentation was not included and the editing was very poor. The current manual is much improved, with GEM documentation and additional example programs. In order to fit the additional information, they made the manual wider (8-l/2 by 7 inches) and reduced the print size (though most users won't have any trouble reading the text).
Overall, the editing is much better, with only an occasional typographical error instead of the content errors I found in the original manual. The style is very readable; it's easy to simply start reading the manual, one entry after another. Like the original version, the manual uses a lexicon format, very similar to an encyclopedia. It's very easy to locate information on how to use the compiler, operating system, GEM or anything else covered in this manual.
However, it's difficult to learn about functions, features and utilities if you don't already know they exist. There is no "function library" section or "Xbios" section to turn to in order to see what is available; you are more or less left to stumble across little gems and treasures as you peruse the manual. Thus, those who don't have the time to read the manual all the way through won't be able to make optimum use of the excellent library support routines available.
The manual is loaded with examples. They are generally very good and demonstrate not only the specific application, but often some of the more esoteric features of C, such as unions. The 3 examples are short, concise and do a better job of illustrating the material presented than many of the books written on the subjects.
Some significant gaps do show up. The symbolic debugger has inadequate documentation, even with two example sessions in the manual. I also had trouble with documentation on the linker when I tried to get separate compile and link times for the benchmarks. I finally had to call Mark Williams for clarification, since all my attempts to use the linker directly for an independent link were unsuccessful. (The final answer was not to call the linker itself but to do all linking through the "cc" command. This is a standard Unix technique but I didn't find it mentioned in the manual.)
Mark Williams' support has improved since I first called them; they now have a toll-free number you can call to get help. The support personnel are quick, and when the phone lines are tied up the receptionist will take your name and number; usually they get back to you the same day. The toll-free number and the call-back procedures are a real relief when you're calling from across the country. Without question, Mark Williams' concern for support is exceptional.
With the exception of the resource construction set, the Mark Williams compiler environment is the most complete development system currently available in one package on the market for the Atari ST. In terms of its phone support, utilities, libraries functions and overall environment, it is in a class by itself. If you have a hard disk and prefer the traditional DOS shell environment with its variety of tools, Mark Williams 2.0 is without equal on the ST. Even if you're working with a floppy system, Mark Williams is a development system that warrants consideration.
(If portability to other systems is important to you, you may also be interested in the Mark Williams C compiler for the IBM PC. The new PC version contains both the compiler package and C source level debugger for only $75 )
Arick Anderson is technical leader with the Curriculum Enhancement department at WICAT (World International Computer-Assisted Training) in Orem, UT.
Mark Williams C Version 2.0, Mark Williams Company 1430 West Wrightwood, Chicago, lL 60614, 1-800-6921700 or (312) 472-6659, $179.95