ST ASSEMBLERS
A START COMPARISON
BY CHRISTOPHER F. CHABRIS
A year ago, the only way a programmer could do serious development work with the 520ST was with Atari's so-called "Developer's Kit" at $300.00. Now. there are several high-level language compilers and four macro assemblers. We'll compare those assemblers and the "standard" Digital Research AS68 program supplied in the developer's kit.
First, though, let's briefly review the function of an assembler in software development. An assembler is a program that translates a source text file composed of mnemonic commands into machine language for a particular microprocessor. On an 8-bit Atari computer, this is exactly what happens. With the ST, the process can be different. Usually the assembler produces something called "object code," an intermediate file consisting of machine language instructions that cannot be loaded and executed directly by the computer. Instead, it must first be processed by a program called a linker.
Why is this? Why not make the assembler simply produce executable files straightaway, like MAC/65 for the 8-bit machines? There are a couple reasons.
First, due to the MC68000's speed and rich instruction set, most commercial programs that run on a 68000-based computer are written in a high-level language like C or Pascal and compiled to run. Although the resulting program runs slower than its equivalent written originally in assembly language, the 68000's speed makes the difference virtually invisible to the user. Software houses prefer to use high-level languages because programs can be developed faster and are easier to port to other computers. Indeed, much of the early ST software was originally developed for other computers in C. Second, because of the increasing complexity of applications software and the large size of the 68000 instructions themselves, executable program code is becoming larger. So, modular programming techniques are gaining popularity, and it is not uncommon to have several programmers working simultaneously on the same final product.
These reasons combine to produce the concept of separate compilation-dividing a large program into smaller modules and compiling them separately only when a change is made. We can create libraries of common procedures just once, instead of each time we compile the program that uses them. Compilers usually produce either an object file (as does Personal Pascal from OSS.) or an assembly language file (as does Alcyon C from the developer's kit). In the latter case, the code would have to be assembled into an object file. In either case, compiling a module results in an object code file output. This is where the linker comes in.
The linker can combine one or more object code files into an executable program under a given operating system. Since the object files are supposed to adhere to a standard format, the linker is even able to combine code from different languages into one program. This scheme makes it easy to write most of an application in a high-level language and code the high-performance sections in assembly language. A notable example is the Unix operating system, which is about 90 percent C and 10 percent assembly language.
For the assembly language programmer, this adds another step to the development cycle, but saves time in large projects. Atari supplies the standard DRI LINK68 program with the developer's kit. Since the linker component defines a development system's object code formats, assemblers and compilers that produce code acceptable to this linker can be used together in the same programming environment.
WHAT IS AVAILABLE?
In addition to the Atari/DRI developer's kit tools, the following assembly language development products were available in April 1986:
- A-SEKA, Kuma Computers Ltd., version 020386 ($39.95)
- GST-ASM, GST Holdings Ltd., version 1.00 ($59.95)
- Macro Assembler, Metacomco, version 10.195 ($79.95)
- DevpacST, HiSoft, preliminary version 0.99 ($79.95)
All four products, as well as DRI's AS68, use Motorola standard mnemonics and conventions. While they are for the most part correct, please do not get the impression that they are compatible with each other! I attempted to perform an informal benchmark to compare the five by assembling and linking an off-the-shelf 31K assembly language source file, (STerminal by Jeremy E. San, from the Antic public domain library). First I tried AS68 to set the performance standard for the others and everything worked fine (it took 3:19 minutes to assemble and a total of 4:21 minutes to create a runnable program file). However, none of the other programs completely accepted the source file, and all for different reasons! The moral is this: choose one assembler and stick with it. Otherwise, you will suffer the same headaches I did attempting to convert source code from one program's format to another. This shouldn't be a problem for developers who want to program from the ground up exclusively in assembly language. Needless to say, none of the four third-party assemblers can be directly substituted for AS68 when developing C programs with the developer's kit.
Interestingly, Metacomco packaged the GST linker with its Macro Assembler. The documentation covers both the GST and DRI linkers thoroughly, but only users with developer's kits will have access to the latter. GST-Link is incompatible with the DRI standard object file format, although Metacomco provides a utility to convert DRI format files to GST (but not vice versa). I'll look at the GSI-Link program and the whole linker issue separately after the assemblers.
Atari provides the SID (Symbolic Interactive Debugger) utility of CP/M 68K fame with the developer's kit. I find it inadequate for all but the simplest tasks, compared even to the tools available on the 8-bit computers. Both A-SEKA and DevpacST include debuggers, while GST-ASM and Metacomco do not.
For program editing on the SI, many developers prefer to use old-fashioned, pre-GEM screen editors that offer speed and familiarity at the expense of ease of use. New programmers may prefer a GEM-based text editor that uses menus to issue commands. Atari has been supplying the Micro EMACS editor, a microcomputer version of a popular Unix tool.
A-SEKA
A-SEKA is the least expensive of the assemblers for several good reasons. Its scant 34-page manual lacks an index and is provided only as a text file on the disk, so you must print it out from the GEM Desktop.
A-SEKA is by far the fastest assembler available for the ST; the manual claims a rate of 30,000 lines per minute, "even for large files," and this is believable. All source and object code is kept in memory until you explicitly write it out to the disk, a scheme that recalls MAC/65 on the 8-bit machines. In fact, the entire package is similar to such products. It has no screen editor, only a cumbersome, anachronistic line editing scheme.
The development process with A-SEKA looks like this: type in your source code line-by-line, correcting and revising with the Edit command; assemble it into memory; execute (and debug) the program using the Go command; repeat this process. Usually, code is assembled directly without linking. Some sort of built-in linker is provided, but the manual becomes foggy here. Apparently, the assembler can produce "linker code" (as opposed to executable code), which can later be combined with other such code into one executable program.
A-SEKA is outdated. While its fast response would be useful for learning 68000 assembly language, and perhaps for writing games, it currently cannot be used for serious development work. It demands revision, meaningful examples, and a completely new manual.
GST-ASM
GST-ASM comes packaged in a green binder and slipcase with 170 pages of unindexed, detailed documentation. It does the best job of all four in providing a complete, self-contained development system for AL programmers. Unfortunately, it is missing a debugger and documentation of TOS/GEM routines. The latter is available in the Abacus book series, but there is no good standalone debugger available as of this writing.
GST has included GST-EDIT, an excellent windowing text editor reminiscent of its 1ST Word word processor, with its own 30-page manual. Here is an example of "overdocumentation," if such a thing is possible. If we could just give some of the extra to A-SEKA! GST-EDIT allows up to four simultaneously open files with a single cut/paste buffer between them. On-line help is available through a pull-down menu.
Although GST-EDIT is now my favorite text editor (replacing Micro EMACS), it has its problems. While scrolling up and down through a file is fast enough jumping to the beginning or end is horrendously slow. More menu selections should have keyboard equivalents for faster operation. Ideally, the Help and Undo keys should also be supported. Most serious, however, is the omission of a Print command in the File menu. I had to write a program to print text files with pagination. This is a problem with all ST editors I have encountered.
The whole package is tied together by an "executive" shell program from which the components can be called, either separately or in batch operations (such as assembling a source file and chaining directly to the linker with default options). Everything makes good, clean use of GEM elements, and assembling and linking speed are comparable to the Atari developer's kit programs, if not better. The option of using the assembler module as a TOS program without GEM overhead is a nice touch, enabling the use of batch file processing. Initially, however, the shell will provide a convenient programming environment.
The assembler itself is complete and, like the rest of the package, well thought-out. Macros, conditional assembly, symbol table and cross-reference listings, and include files are all supported. Clearly this assembler was designed to support high-level languages-there is a COMMON directive that the manual connects to Fortran! The standard EQU, XREF, XDEF, DC, DCB, and DS pseudo-ops are available, as well as many others. The macro facility is extensive, including several "pseudo-functions" such as .LEN and .INSTR that can be used in string substitutions. GST thoughtfully includes a library of useful macros for conditionals, loops, stack handling, and subroutines. Assembler errors are all carefully documented, but TOS errors are not. (They are usually fatal anyway, the manual claims)
GST has done an excellent job of making assembly language development accessible to ST users. Let's hope they're working on a debugger of similar quality!
METACOMCO
Metacomco, an acclaimed system software developer in the 68000 world, has done a good job with its ST Macro Assembler package. It is the only package to provide an example source listing of a program that makes GEM calls, but like the others provides no real documentation.
ED is Metacomco's standard, simple, full-screen TOS-based editor, and is similar to Micro EMACS. It is adequate for working with assembly language source files, but takes some getting used to. It has some nice features, such as the ability to specify the text buffer's size and to continue executing a command (such as search and replace) until an error condition arises.
The assembler came closest of the four to functioning as a replacement for DRI's AS68. It has all the features of GSTASM, plus local labels; but the macro facility is much weaker and no library of macros is provided. Strangely, two directives that do absolutely nothing are provided, yet there is no EVEN pseudo-op to make sure the following code begins at an even address. The manual documents the LINK68 linker, which is not supplied on the enclosed disk. However, the instructions for assembling the sample programs (provided in printed form only-aargh!) apply only to LINK68 and reference libraries not included on the disk. GST-LINK and its manual, identical to that in the GST-ASM package, are included. Metacomco's manual is typeset and carefully indexed, but does not accurately reflect the contents of the disk. This is a vanilla program-I suppose it lives up to its claim of being "full specification" but it is not as complete as GST-ASM. (Of course it beats A-SEKA!)
HISOFT DEVPACST
HiSoft, a well-known European developer, was still working on their DevpacST in April 1986. I was furnished with a copy of version 0.99. (The final release is to be 1.00). Even so, the manual was bound and the packaging complete. DevpacST strikes a middle ground between the fast, loose, in-memory approach of A-SEKA and the formal edit-assemble-link paradigm of A568, GST-ASM, and Metacomco's Macro Assembler. Its editor and debugger are both window-based, but it does not provide a linker.
EdST makes full use of GEM but provides only one text editing window The amount of free memory and the current row and column are displayed at the window's top. On my 520ST with TOS in ROM, there were only about 60,000 free bytes- a small buffer when it is the only one you have to work with. For large programs the editor's restrictions could be severely limiting. EsST allows several methods of command entry including: drop-down menus, keyboard equivalents, and WordStar-like equivalents.
When you are ready to assemble your source file, you just choose the Assemble command (Alt-A) and a 2-pass assembly process occurs. The assembler supports the same standard features as the others, but the options for listing generation, macros, and conditional assembly are even more limited than Metacomco's. There is not much to say here except that the assembler still had a couple of serious bugs in version 0.99. The assembler and editor are only available from the GenST shell, and no linker is employed.
The highlight of DevpacST is the MonST debugger. It uses four non-GEM
windows: 68000 register value display, hexadecimal memory dump, disassembly
(normally of instructions near the Program Counter value), and command
entry! response. After loading MonST, you are prompted to enter the name
of the program you want to work with, which is then loaded into memory.
MonST preserves the program's screen and requires only about 12K of memory.
MonST is automatically invoked whenever an exception occurs. You can set
and clear breakpoints; single-step; view the program's screen; disassemble,
search, examine, and modify memory; and modify the processor registers.
This is a good first debugging tool.
not an intuitive program...you
cannot usually "pick it up" as
you go along.
The short, 40-page manual is poorly written, even compared to A-SEKA's documentation. It needs expanding, rewritting, and proofreading. One nice touch is a list of known bugs in version 0.90. HiSoft promises various improvements in version 1.00 of DevpacST, including bug fixes, GEM AES and VDI constant and macro definitions, source to a complete application (this would be revolutionary!), external references, and the ability to produce linkable object files. I cannot recommend the current version, but 1.00 should compare favorably with GST-ASM and Metacomco if HiSoft delivers on its promises. Perhaps they will also index the manual...
GST-LINK
GST-LINK, which is included with GST-ASM, Metacomco's Macro Assembler, and other language products from both companies, supports an object file format that is fully documented in the manual. It normally takes its input from a control file specifying which files are to be linked in what order to form the executable program. The control file language ineludes commands for setting the stack size, extracting modules manually and automatically from library files, and defining new labels (useful for correcting typographical differences between modules being linked). GST-LINK also produces executable programs directly without the annoyingly necessary RELMOD application used by LINK68.
GST-LINK is becoming popular in ST software development and is generally superior to LINK68, found in the developer's kit, but the incompatibility between the object file formats accepted by the two may cause problems.
For the programmer who is selecting one and only one language development environment, the question of linker compatibility is relatively unimportant. However, if you have any intention of combining languages, porting between development environments, or using standard libraries provided only as object files (for example, the LIBF Motorola fast floating-point library supplied by Atari in the developer's kit), the lack of a standard could complicate and retard ST development progress. I like GST-LINK (although LINK68 and the Personal Pascal linker have been adequate for all my needs so far), but a standard format is needed.
SUMMING IT UP
I recommend GST-ASM as the most professional and complete package, and as the best value. Metacomco's Macro Assembler is comparable and desirable for use with its other language products. DevPacST in its current version is unacceptable, although its debugger is useful and version 1.00 has potential. A-SEKA is woefully inadequate unless you want to learn 68000 assembly language in an interactive environment. But if you already have Atari's developer's kit, you could safely stick with good old AS68 and LINK68 without falling behind the competition. I hope GST-EDIT is released separately for users who do not need the entire package.
Documentation is one of the most important aspects of a language environment. Before purchasing any of these packages, including the Atari developer's kit, carefully examine the documentation to make sure it provides you with enough information to effectively use the product. An assembler is not an intuitive program like a GEM-based word processor-you cannot usually "pick it up" as you go along. Unfortunately, none of the packages include sufficient examples or information on accessing system routines for a programmer to get started without other sources. C source code is much more plentiful than assembler in the ST world, so you should be prepared to do some work before you begin programming. The rewards of a successful GEM program in fast 68000 assembly language will be well worth the effort!
LIST OF MANUFACTURERS
Atari Corp., 1196 Borregas Avenue, P0. Box 3427, Sunnyvale, CA 94088-3427, (408) 745-2000
Kuma Computers Ltd., 12 Horseshoe Park, Pangbourne, Berks RG8 7JW, United Kingdom, 07357 4335
GST Holdings Ltd., 91 Hight Street, Longstanton, Cambridge, England
Metacomco, 26 Bristol Square, Bristol BS2 8RZ, United Kingdom
HiSoft, 180 High Street North, Dunstable LU6 IAT, United Kingdom, 0582 696241
The Kuma, GST, and Metacomco assemblers are available in The Catalog in this issue.
REFERENCE:
-
Introducing 520ST Assembly Language by Christopher Chabris, Antic magazine,
December 1985
-
Atari ST Internals by K. Gerits, L. Englisch, and R. Bruckmann, Abacus
Software, Grand Rapids, MI
-
Atari ST GEM Programmer's Reference by Norbert Szczepanowski and Bernd
Gunther, Abacus Software, Grand Rapids, MI
-
Atari ST Machine Language by B. Grohmann, P Seidler, and H. Slibar,
Abacus Software, Grand Rapids, MI
-
COMPUTE!s ST Programmer's Guide by The Editors of COMPUTE!, COMPUTE! Books,
Greensboro, NC
-
68000 Microprocessor Handbook, 2nd ed., by William Cramer and Gerry Kane,
Osborne/McGraw-Hill, Berkeley, CA
-
68000, 60010, 68020 Primer by Stan Kelly-Bootle and Bob Fowler, Howard
W Sams & Co., Indianapolis, IN
- Mastering the 68000 Microprocessor by Phillip R. Robinson, Tab Books, Ridge Summit, PA