REVIEW
Someday, you'll be writing programs in several languages. You might as well plan for that eventuality now.
Metacomco Overview
The Programmer's Source:
a survey of development tools from Metacomco
Menu v 1.2 $29.95 Metacomoco Make v2.16 $69.95 Lattic C v3.04.01 $ 149.95 MCC Pascal 68000 v1.35.04 $99.95 Metacomco BCPL v1.11 $149.95 Cambridge Lisp v1.10 $199.95
Metacomco pic
26 Portland Square
Bristol BS2 8RZ, UK
(0272) 428781
by Tom Castle
Tom Castle is an M.S. Chemist in Kalamazoo, Michigan. He bought his first personal computer, an Apple II, in 1980, but had no hesitation switching over to his Atari 1040ST. He spends most of his programming efforts using C on the Atari and Turbo Prolog on IBM machines.
So, you're interested in programming on the Atari ST. If you're not fluent already in a given programming language, you'll probably be asking which language is the best to learn. The answer is an emphatic "Any of them!" Each language has strong and weak points. Some are particularly useful for a specific application. Others are more generally useful with the concomitant sacrifices that go along with all-purpose products.
The general-wisdom advice floating around is to start with a language for which you can find help. BASIC has always been a popular choice, but C is quite in vogue. Pascal and its child, Modula-2, were expressly written as languages with which to learn programming. There are several, readily available sources of information and help, such as magazines, books, user groups and bulletin boards for all those languages.
Once you decide on a language or if you already feel comfortable with a particular language, you then have to decide on which package you'll drop your hard-earned money. Again, for a little sage advice, look at the features, at how much support you'll get from the producer and the development community, and at price. You might also look at the future.
If you take up program development with a fervor, someday, you'll be writing programs in several languages. You might as well plan for that eventuality now. Metacomco, a major producer of the development tools for Motorola 68000-based machines, has anticipated your need. The development tools currently available from Metacomco for the Atari ST are Menu +, a GEM shell; Make, a UNIX-like utility for riding herd on projects; and the language products Lattice C, MCC Pascal 68000, Cambridge Lisp, BCPL, and the MCC Macro Assembler.
Not only do these products integrate well with each other, but several can be used to cross-develop on other computers. Metacomco's Lattice C is directly transportable to the IBM and Amiga versions of Lattice C. Metacomco specifically includes functions to provide UNIX, XENIX, and ANSI compatibility. Cross-development for the Amiga computer is particularly easy since Metacomco also produces MCC Pascal, BCPL, and Cambridge Lisp for the Amiga.
The Subject
For those of you new to compiled languages, a quick review of some of the terms should be in order. Each microprocessor, the Motorola MC68000 in this case, has a unique set of special memory spaces called registers. To manipulate data within those registers and within the main memory of the computer, operations must be programmed using a distinct instruction set. That instruction set is a set of numbers that the microprocessor will recognize as commands for it to perform given tasks. Programs written in this purely numerical code are called machine language. The command instructions are called opcodes. The data to be operated on are called operands.
An easier way of specifying opcodes and operands is called assembly language. For readability, the numerical opcodes are replaced by a set of mnemonics that each represent a given operation. Assembly language has a means of labelling constants, variables and points of a program. In addition, the other conventions are included to aid writing assembly language programs. Assembly language is considered low-level because it performs very closely to the actual workings of the computer. The conversions of an assembly language file into machine language is done by an assemblyer. The resulting machine language file is called an object or binary file.
The conversion of a high-level language into an object file is done by a compiler. Languages are termed high-level if they have the computer performing complex tasks in such a manner that the programmer doesn't have to worry about the details of how the task is accomplished. The text flies that you write for a program, whether for an assembler or a compiler, are called source files. Usually a compiler will produce an assembly language or a pseudocode file before the final object file is produced. Each time a compiler must go over the text file to produce the object file is called a pass. So a single-pass compiler is easier, though presumably less versatile, than a multi-pass compiler.
Once a final object module is created, it must be treated by a linker program to make an executable program file. The linker usually connects some initialization code and any library routines that weren't resolved in all the object modules you specify.
Common Ground
If you do buy several development tools in the future, you may find yourself in the middle of a hodge-podge unless care is taken. Usually you can find an assembler that will produce modules that can be linked with those from high-level language compilers, but you may run into trouble linking modules from different high-level languages.
One of the nicest features of the Metacomco products is that any module produced by one product can be linked with modules from any other product. You have the possibility of writing modules in the language that is most suited to a particular section of your program and still come up with a unified package. If that isn't enough, all Metacomco products have the option to produce CP/M-68K object files for linking compatibility with Digital Research's LINK68 from the Atari Developer's System. Metacomco doesn't provide that linker with any of its products however. A nice feature of Metacomco's language packages is that they all include the assembler source files for the GEM functions.
Menu +
Each of the language products from Metacomco comes with a GEM shell called Menu +. You're able to customize drop-down menus that will perform the instructions you place in a batch file for each menu selection. This is one of the most useful products I have seen in a long time. If you have done much programming, you know that it's no fun hunting for your BATCH.TTP file among the myriad of files you build up in your compiler or linker folders.
Your customized menus and the associated batch files are coordinated through a file called MENU.INF. Prototypes of this control file come precon-figured for use with Metacomco's Lattice C, MCC Pascal, and MCC Macro Assembler. You can still alter these as you want.
Menu+ not only organizes your work space but also provides some handy utilities. A command line interface is provided for commands that aren't included with the drop-down menu. A history is generated every time you access Menu +. This isn't only provided for recollection's sake but also as a convenient method of repeating any command line by double clicking the particular line in the history. A UTIL.TTP program is included to perform functions like renaming, deleting, copying, showing, and printing files. This relieves the need to return to the GEM Desktop for those operations.
Menu + doesn't have to be used solely with Metacornco's development products. It can be used with any development package; in fact, with any set of application programs. Although it's bundled with all of Metacomco's development packages, it's also sold separately. If you have a need to harness your desktop a little better, Menu + is well worth the investment. It is very versatile and fairly inexpensive.
Metacomco Make
The other non-language develoment tool provided by Metacomco is their Make program. It's sold separately and bundled with the Lattice C package. For those of you who are familiar with the UNIX Make, you'll feel right at home. It comes with a nice GEM-based screen editor, a prototype control file (called a makefile), a clock adjustment utility, and a Touch utility to update a file's date stamp without altering the contents.
Briefly, Make allows you to set up a programming project such that file dependencies are outlined and automatically managed by Make. For example, you might have a main program module that requires a separately linked module to be included. If the separately linked module is changed in any way, Make will detect the change, and recompile and assemble both the new module and the main program portion automatically.
Makefiles are generated by the user for each programming project. A variety of instructions are available for maximum flexibility in setting up a makefile. Explicit rules define file dependencies by the actual names of the files along with the exact command sequence you want followed. Implicit rules only consider file types when determining which files should be treated. Macros and control directives are also supported.
For those of you who are familiar with UNIX Make, there are some differences to be mentioned. Make uses makefiles rather than the built-in implicit rules of UNIX Make. The directives .DEFAULT and .PREVIOUS as well as the macros ‘$?’ and ‘$%’ are not supported by Make. The ‘::’ form of explicit rules is not supported also. Tab characters are not essential as in UNIX Make, and colons must be separated by a space since colons have a special meaning in file path notation of GEMDOS.
Screen Editor
The screen editor included with the Make package is also included with all the language products. It uses drop-down menus as well as keystroke commands. ED, as Metacomco calls their multiple-window screen editor, uses a fixed-size text buffer which defaults to about 64K but can be changed easily. Scrolling can be performed horizontally or vertically with a message and command-line area at the bottom of the screen.
There's quite a variety of commands available with ED. Twenty-one immediate commands are peformed by either a single keypress or a control-key combination keypress. Most of those commands are used for cursor control, inserting and deleting text, and such. There are also 38 extended commands that must be typed at the command line. Those commands are used mostly for things like block operations, formatting, and search and replace functions.
The editor is quite useable, although the mouse is not supported in the text field. There is no provision for displaying line numbers.
Lattice C
Atari ST programming is heavily sided toward the use of C. This is most probably due to the fact that a lot of GEM was written in C. The DRI documentation and software in the Atari Developer's Package supported only the use of C. Although Lattice C was not one of the first C packages to be available for the Atari ST, the compiler already has a prominent reputation. It's considered by many to be the foremost C compiler for the IBM PC line.
Lattice C comes with several amenities not included with Metacomco's other language products. As mentioned before, Lattice C comes bundled with Menu+ and is the only language product that comes with Metacomco's Make and Debug + programs.
It's also the only package that comes with a resource construction kit, NRSC, which enables the rapid development of resource files containing menus, dialog boxes and the like. Header files can be created with the program for C, Pascal, Modula-2, Fortran 77 formats. Metacomco also claims that no special programming is needed to conform the resource file to either medium- or high-resolution monitors. It should automatically adjust to the monitor in use. I don't have a monochrome monitor, so I wasn't able to test this claim. NRSC is upwardly compatible for resource files created by the Atari and Mega-max C packages. It does have a few extras, however, that could jeopardize compatibility in the other direction. It supports the use of two additional flags that can be set by the user for extensible types of objects.
A symbolic debugger, disassembler, and link loader called Debug+ is provided with the Lattice C package. You can display memory as hexadecimal and ASCII dumps or as a dissassembly listing. The debugger uses the symbols generated at the end of a program by the -DEBUG linker option. The link loader will install the object module and any library modules into memory, resolve intermodule references in preparation for debugging. Debug+ has a rich set of commands that let you display the entire symbol table, dissassemblies, dumps, and memory locations of any symbol. User-selectable breakpoints can be inserted in your code, or you can use the STATE command to examine register contents and the current assembly instruction. Any variable can be examined at any point in the debugging process. Debug+ also lets you use predefined or user-defined macros to speed up the debugging process. A WHERE command will tell you what C function is currently being examined. Commands are also provided to trace forward and backward through a program. Thirty-one commands are provided altogether.
The Lattice C compiler is complete. The full Kernighan and Ritchie specification is included with extensions to conform to the ANSI standard. As mentioned earlier, functions providing both UNIX and XENIX compatibility are included. In fact, there are so many functions included in the runtime library, a little over 320 in all, you could easily be seduced into using alluring functions that will destroy any chance of compatibility with other C compilers for the Atari ST. This isn't good for your ST-Log submissions. In fact, compatibility with other C compilers for the ST must be meticulously handled since Lattice C is the only C compiler that uses 32-bit integers. Careful, careful!
Even with the caveats, it's a nice compiler. Line A calls—the code that GEM's VDI uses to draw graphics primitives, to manipulate the mouse form, to perform bit and text block transfers, and to manipulate sprites and rasters—are included. Double-precision floating point as well as MC 68881 Math Coprocessor support is available.
There are three levels of memory allocation which can be called. Level three functions call level two functions, and so on. There are also three levels of file access. GEMDOS, BIOS, and XBIOS system traps are supported. Qsorts for all the variable types are included. A full set of string manipulation functions are also included.
You can easily be overwhelmed by Lattice C if you're not already familiar with C. However, you'll never outgrow this product. The 600-page manual covers the compiler, linker, and all accessory programs in great detail. Each function is thoroughly described, many with example code fragments for the more complex functions.
MCC Pascal
Pascal was originally written by Niklaus Wirth in the late ‘60’s based on the popular language ALGOL. Wirth formulated the language as a teaching tool for the instruction of proper, structured programming techniques. Large programs are segmented into structured blocks which can be nested, but not overlapped. The block structure encourages "top-down" program development. A skeleton can be written while the various levels of detail can be tackled as you come to them. Pascal has since become one of the most widely used languages. It's one of the most readable and readily accomplished languages. This is testified by the abundance of Pascal packages for the Atari ST.
MCC Pascal 68000 offers a single-pass compiler that produces native 68000 code rather than a p-code. As mentioned earlier, this allows Pascal object files to be linked with object modules from any of Metacomco's other languages. A rather complete error reporting system is included.
The implementation also conforms to the ISO 7185 (level 0) standard. This is important for portability considerations. Very large arrays and sets are limited only by available memory. MCC Pascal has just about as many classifications of variables, imaginable, including 1- and 2-byte integer subranges, variant records, booleans, 4-byte pointers, and file types among others.
Although all the GEM VDI and AES bindings are accessible, no resource construction set is included in the package. Like the Lattice C compiler, integers are expressed as 32-bit values. MCC Pascal also uses 32-bit, 7-digit precision real numbers. Indentifiers can be of any length, and all characters are considered.
There are a few extensions to the ISO standard included with MCC Pascal. The RESET and REWRITE procedures are included so that internal files, those that exist only during the execution of the program, can access named files. The INCLUDE and EXTERNAL directives allow modular inclusion of program fragments during the compilation process. Shades of Modula-2! MCC Pascal wasn't extended to include bit-wise operators however.
The MCC Pascal manual disclaims the idea of being a language tutorial. It is, however, a nice explanation of the language elements and syntax. Three example programs are given which show how to access GEM features, to call assembler language routines from Pascal, and other nifty things.
MCC Macro Assembler
Now that you feel comfortable with the popular high-level languages, it's time to delve into the bowels of programming, the assembler. The MCC Macro Assembler package, like the Pascal product, disclaims the idea that it is a tutorial. This is an understatement. The manual does not even list the 68000 instruction set. It does, however, contain a fairly thorough treatment of addressing modes, coding conventions, and syntax. The assembly control directives, along with the facility for conditional assembly, are thoroughly explained. There is also a bouncing-ball example program and the source code for the GEM routines.
Several options of the assembler control file output. The MCC Macro Assembler can produce GST or TOS format object files or simply a listing file. Symbol dumps and cross-reference tables can be generated also. You have the option to make the assembler insensitive to label upper/lower case distinctions.
The source code of a simple debugger is included. This seems to be more for the purpose of illustrating some TOS features than for the purpose of providing a highly useful debugger.
There are some ups and downs to the MCC Macro Assembler. Local labels are supported. That's good. No macro libraries, other than the GEM VDI and AES stuff, are provided. That's bad. One nice thing is the facility to include files by the assembler directives HDR (header), EQU (equate), and INC (directories from which INCLUDE files should be searched).
BCPL
Well, maybe you're not quite ready for assembly-language programming but want the enormous power that "low-level" access can bring to you. The C language provides access to the inner workings of the computer, but it's not the only alternative to assembly language programming. There's a predecessor to C that's even less restrictive to the programmer than C. It's called BCPL. I had never heard of it. My friends had never heard of it. It seems to be widely used though. Metacomco wrote AmigaDOS in BCPL. It must be like Slim Whitman—it's so darn popular in Europe.
If Pascal is the fascist of variable typing, BCPL is the anarchist. BCPL uses data words of 32 bits. It doesn't care how you want to use them. They can be pointers, integers, packed characters, booleans, or whatever bit pattern you want.
There is some structure to variable usage, however. From the vein of BCPL flowed the C tradition of strings as pointers to the byte-by-byte pack. Un-like C, the memory occupied by the character array starts with the length of the array followed by the characters. BCPL also incorporates vectors which are arrays of data other than character strings. Tables, which are initialized vectors, are also used.
Like C, BCPL passes parameters by value and controls them by scope. To be specific, variables can be Manifest, being a globally defined constant; Local, existing only in its prescribed block or procedure and being deallocated upon exit from the block or procedure; Static, retaining its value throughout the execution of a program but having a local scope; or Global, being available at all times.
Metacomco's BCPL manual is probably the most instructive of its language products as to the explanation of the language elements. The BCPL environment and memory-usage map are given in an appendix. Six example programs are given, exemplifying input/output, switch-case constructs, data manipulation, flow control, and GEM functions. A detailed description of each library function is provided in the manual.
Metacomco includes a few extensions to the language. Floating point operations are not usually a feature of BCPL, but Metacomco provides single precision real numbers and a few functions that allow real integer conversions. A WORD indirect operator is provided to manipulate arrays of 16-bit values like the control arrays returned from initializing a GEM workstation. The EXTERNAL Keyword is included with BCPL, like Metacomco's other language products, to allow interfacing to C and Assembler routines. They have also added procedures for those of you who would understand the importance of that.
Cambridge Lisp
The last language product for us to examine is Metacomco's Cambridge Lisp. With all the hoopla over artificial intelligence over the last few years, you might think that Lisp is a fairly new language. The truth is that Lisp was invented by John McCarthy in the late '50's. We're talking vacuum tubes here. Lisp stands for LISt Processing. It relies heavily on recursion and the basic data structure, a pair. From those two ideas, lists and trees can be created and manipulated.
Lisp is used in a variety of applications that are not well-suited to procedural languages. Natural language query interfaces, symbolic algebra, robotics, and expert database systems are all fertile fields for Lisp. In fact, any application that's heavily decision-based is ripe for Lisp.
There has been sufficient time since the inception of the original Lisp for several dialects to emerge. Metacomco describes Cambridge Lisp as a member of the standard Lisp family with close similarities to PSL, Portable Standard Lisp. A nice feature of the manual is to point out differences between Cambridge Lisp and other Lisp systems, particularly MacLisp, Interlisp, and Common Lisp. An appendix lists the extensions available in Cambridge Lisp that are not found in standard Lisp.
There are two considerations that set Lisp apart from Metacomco's other language products. First, it's basically an interactive language. Most of your interaction with Lisp is through the Supervisor, a read-evaluate-print loop interpreter. Anyone who has programmed in BASIC will attest to the ease of program develoment under an interpreter rather than a compiler-based system. Cambridge Lisp offers both.
Second, it's a declarative language. Rather than setting down a procedure for the computer to follow, you give the computer the means to process basic data structures and evaluate expressions while letting the computer figure out how it will go about the task.
Cambridge Lisp is a large language. There are about 400 standard functions along with the facility to define your own functions. That does not include the GEM routines. You can easily see that Lisp was originally developed for mainframe computers. Metacomco suggests a full megabyte of RAM in your ST to take full advantage of Cambridge Lisp, but the system is still quite useable on a 520ST.
There are several facilities that enhance Lisp implementation. Cambridge Lisp provides full garbage collection and error reporting. A built-in prettyprinter is provided. Cambridge Lisp also provides the facilities to access double precision IEEE format-floating point numbers, rational numbers of the form (27/513), and trigonometric functions, and to use several input/output streams, and to customize syntax.
Cambridge Lisp also has some amenities to make programming chores easier. The old program feature of Lisp that allows a section of code to be enclosed with loops and local variables is retained. The catch and throw functions are also available to make nonlocal jumps. A system for creating includable modules is also present.
Error handling and debugging is made easier with some of Cambridge Lisp's functions. A few functions let you retain a moderate amount of control over the program even when serious mishaps occur. You can customize the amount of error reporting and how much backtrace information you want for given situations. Cambridge Lisp also provides several functions to perform trace, history, and logic mapping operations. Tracing can be performed in either interpreter or compiler mode.
I won't attempt to give a synopsis of the language itself. That would be a monumental task. Lisp is different from all the FORTRAN descendents with which you may be familiar. It's probably sufficient to say that learning Lisp will not be easy, especially if you are already in the procedural mindset of C, BASIC, Pascal, or assembler language. It would also be safe to say that once you are comfortable with Lisp, you'll be able to write efficient programs that can't be written easily in another language.
Conclusions
Metacomco has a fairly diversified line of programming-development tools. The Menu + program is especially useful even if not used or purchased with one of the language packages. Make, as any UNIX programmer will tell you, is nice for those large projects. However, if you're a middling dabbler like me, it may not be worth the expense and time to use.
The products that Metacomco should release as stand-alone packages are the resource file editor (NRSC) and the debugger (Debug+), which are included with Lattice C. The unavailability of NRSC and Debug + to the Pascal, BCPL, Lisp, or assembler language programmer makes those packages look less attractive.
Metacomco's strong suit is Lattice C. They've included everything you would need for a professional development system. This isn't surprising since Atari/DRI promulgated C as the language of choice for GEM and the Atari Developer's Kit.
Lattice C should do well since it offers IBM and Amiga compatibility. The Alcyon C compiler from the Atari Developer's Kit will provide IBM compatibility under GEM, but provides no support for XENIX or UNIX.
The Lattice C manual is somewhat bug-ridden. The first 30 pages of mine were scrambled. The manual also, on occasion, uses British spellings for GEM functions like form__centre, but the linker will spit these back out to you. Overall, though, it's a good package, and a strong contender in the C market.
The strong points of Metacomco's other languages are the common linker and the ability to compile code to either CP/M-68K or GST format object files. However, few people will currently need several languages that produce compatible object modules. Initially, an assembler that's compatible with your higher level language may be all that you need. It's comforting to know that it's available, though. In fact, who's to say that you won't need that sort of latitude some day? It gives you some peace of mind that it's possible to expand your language repertoire with the confidence of compatibility.