REVIEW
Laser C 2.0 – $195 Laser DB –$70
Megamax, Inc.
P.O. Box 31294
Dallas, TX 75231
(214) 699-7400
Reviewed by Darek Mihocka
When I sent my check to Megamax, Inc., for the Laser C update, I was a bit skeptical about what I would receive. After all, Megamax was asking $50 for the upgrade, which was more than double the upgrade cost for the first version of Laser C, and so far, all of their software has had some pretty annoying bugs. I've already lost track of how many phone calls I've made to Megamax over the last year to report bugs. But after installing the new disks on my hard disk and playing around with it, I was satisfied that it was money well spent. Here's why.
Laser DB
The shining star of the Laser C 2.0 package is the new debugger, Laser DB. For the first time, Megamax offers source-level debugging of C code and symbolic debugging of assembler code and code not compiled by Laser C.
When I first saw Laser DB, I wondered why they hadn't just gone ahead and called it Codeview Junior. Being a regular user of Microsoft C and Codeview, I was delighted to finally see a product on the ST that is almost as good. I say almost because a few features are missing from Laser DB.
To run Laser DB, you can either click on the Debug menu entry in the Laser C 2.0 shell or run it from the desktop. In either case, a dialog pops up, prompting for the name of the target program to debug, the command line (if any) and the debugging modes: source, assembly or both.
Figure 1 shows a typical Laser DB screen in source-code mode. It is composed of four windows: Watchpoint, Code, Expressions and the Register/Stack window. Each window can be selected by clicking on it with the mouse or by pressing an appropriate key. The first three windows can also be resized by clicking the top of the window with the mouse and dragging. The Register/Stack window can be hidden if you wish to debug only at the source level. Clicking on it changes the display between a register dump and a stack dump. Figure 2 shows the assembly-level display with a register dump.
The power of Laser DB doesn't become apparent until a piece of compiled code starts to mysteriously crash and put cherry bombs on the screen. Usually, panic sets in. I used to load up my code with printf() calls, but this is not always helpful. Having a memory-resident debugger, such as the excellent Templelmon program loaded at all times helps by showing the exact machine-language instruction that generated the exception. But such utilities can't display symbols or help you locate the line of source code that is at fault.
With Laser DB, any time the 68000 generates an unwanted exception, such as a bus trap error or illegal instruction error, the 6800 registers, as well as the offending address and other related information, are displayed in the register window, the 68000 registers are displayed in the register window, as well as the offending address and other related information. At this point, one can look at the assembler listing to see the instruction that generated the exception. Pressing Control-M switches the display to the source mode to show you the exact line of source code that needs to be fixed.
Laser DB uses a separate screen for its display, thus allowing it to debug any GEM-based program. A Flip command switches between the two screens. Laser DB also grabs control of all the important system vectors, including the Alt-Help vector, making it difficult (but not impossible) to generate screen dumps. In fact, Alt-Help is used as the break key.
If that was all the Laser DB did, it would hardly be worth its price, considering the availability of public-domain debuggers. But, like Codeview, it offers more.
The watchpoint window can display up to ten watchpoints. A watchpoint is an expression that is evaluated each time Laser DB is in control. For example, Figure 1 shows part of the program I used to generate the Laser DB screen shots. The Watch window is displaying the value of two pointers as the program searches through memory looking for Laser DB's screen. In the Expression window on the bottom, I asked it to show me the filename to which the screen shot is being saved. Both the Watchpoint and Expression windows support C-like expressions, allowing evaluations of both simple integers and complex pointer expressions. There are some predefined symbols that are used to access the 68000 registers, code and data segments.
The Laser DB manual is small, about 80 pages, but describes all of the features quite well. Single keystrokes access most of the functions, and there is a menu bar;that can be accessed with the mouse. The menu bar is not a standard GEM menu bar; it is similar to the type of menus seen in programs like Lotus 1-2-3. Pressing the first letter of a menu entry selects that menu entry, and the escape key always takes you to the top menu.
Search functions are also provided. The search can be for a particular string in the source code, or a label in the object code. This feature can be used when debugging a large program.
Laser DB also has a Journal window, which displays the last 100 lines of code executed. This can be useful when trying to determine the cause of erratic program behavior, although it does not log the actual bus activity. A Calls window displays a traceback of the stack, showing all function calls and their parameters.
A standard feature of any debugger is the ability to set breakpoints. Laser DB is no different. To set a breakpoint, simply scroll the Code window to a particular line of source code and click on that line with the mouse or press the asterisk on the keyboard. There are fancier variations on that theme, such as optional breakpoints. These types of breakpoints interrupt the program when they are reached only if some expression is true. For example, only break if the return value of a BIOS call is nonzero.
Finally, there are several ways to debug the target program. You can select the Go command, which runs your program until it either crashes or reaches a breakpoint, or until you press the break keys (Alt-Help). The Trace command does the same thing, except it continually single-steps through the program, updating the Watch and Register/Stack windows after each instruction. The Step command single-steps under user control and can be used to step through either the source code or assembly code. You can choose to step through or step over subroutine calls.
Compared with Megamax's previous debugger, Laser DB is a fantastic improvement. I was pleasantly surprised to find no major bugs in Laser DB either. The only major flaw is its inability to log sessions to disk or to remotely debug through the serial port. Remote debugging would be required in situations where memory is so tight that Laser DB would not fit along with the target program. In that case, only a small portion of the debugger remains in memory, while the rest runs on a separate machine. Atari's developer's kit provides such a debugger.
Debugging a target program not compiled by Laser C is possible, but only at the assembler level. If a symbol table is included in the executable file, the symbols can be used; otherwise, you debug in hex! Fortunately, most other packages can generate symbol tables.
Laser C 2.0
Laser C 2.0 is twice as good now, right? No, not really. As it turns out, Laser C 2.0 offers only a handful of new features. The desktop is similar to the original in that it offers a built-in editor capable of editing up to four text files simultaneously; a disk cache for speeding up all disk operations, an STDIO output window (which doubles as a command-line shell); and a set of drop-down menu entries for calling up the compiler, linker, debugger and other programs. For a detailed look at the original Laser C, see my review in the November '88 ST-LOG.
Laser C 2.0 will run on a 512K machine, but its powers are severely limited by the lack of memory: One cannot take advantage of having memory-resident tools or edit large source-code files. I highly recommend using a Mega ST with Laser C, but if you're like me, a 1040ST with a fast hard disk will do fine.
The editor has been enhanced with a few new options, such as selecting the entire buffer. This is handy for clearing out the STDIO window in a hurry. Figure 3 shows the Laser C 2.0 desktop with four source files being edited, plus the STDIO window.
The editor uses a dynamic memory-allocation scheme that is closely tied in with the disk cache. This is both a blessing and a curse. As I mentioned in the first review, the disk cache can't be disabled. This is fine if you have plenty of memory, as this allows you to store all your tools, source code, object code and executable code in memory at once.
It results in extremely fast compiles, but with a price. As memory starts to fill up, especially when editing large source-code files, the cache must start making decisions about which files will be kept in memory and which will be flushed to disk. On a 1040ST, this can happen quickly, and performance drops off fast. A compile-and-link operation that takes 20 seconds to complete with an empty cache takes 50 seconds the second time around. This is more than twice as slow.
In all fairness to Laser C, the problems don't appear to be totally its fault. When I tried running Laser C with TOS 1.4, the performance increased to almost empty cache levels. Unfortunately, 99.9% of ST users do not yet have TOS 1.4, so a cache-disable option would still be desirable.
The editor now has the ability to print the buffers, and a printer setup feature is provided.
The compiler and linker have changed very little, except to support Laser DB. With the Z flag enabled, the compiler and linker will add extra debugging information to the executable file. This extra information can easily double the size of the executable module and should only be used during development. More on the debugger later.
The compiler now fixes some of the code-generation errors in the inline assembler. The new linker also fixed a bug I found earlier. I once accidentally generated an object file that contained 65K of code. When I tried to link it with other modules, the linker bombed! As it turns out, the old linker couldn't handle object files greater than 64K.
Unfortunately, the compiler still does not support function prototyping, a feature found on most DOS and UNIX compilers and an essential part of the ANSI C standard. Hopefully, future versions of Laser C will support this, since it is an easy and painless way of avoiding program crashes caused by careless coding.
The resource-construction program is now up to Version 3.0, although I fail to see much of a difference between it and previous versions. The one obvious addition is the ability to read and write the new .DFN file format used with Atari's Resource Construction Set 2.0, as well as the older and more common .DEF files used with other resource editors. In fact, Megamax's RCP is the only one I know of that can easily convert from .DEF files to .DFN and back. Figure 4 shows the Laser Resource Construction Program.
The RCP is also claimed to have the ability to generate C code from resource files. So far, only Atari's RCS 2.0 has this ability. Unfortunately, the "code" it generates is nothing more than a static array of integers, rather than the neatly commented structures and arrays I was expecting. Laser C 2.0 provides a mrscr—load() library function to replace the usual rscr—load() function. This works nicely and makes the task of compiling resources into the executable code almost invisible.
One other nice feature of Laser C 2.0, which was around before, is the Disk Ops dialog, shown in Figure 5. It provides a quick method of performing disk operations without having to exit to the ST desktop. Deskcart and the Universal Item Selector II provide similar features, but if you don't already have these programs, you don't need them.
In a nutshell, if you already use Laser C 1.0, don't expect Version 2.0 to add much. But do send in for the update so you can use Laser DB.
As Good as You-Know-Who?
One does not have to look far to see the direction in which C compilers are going. Several packages for the ST, including Turbo C, Prospero C and Laser C are emulating the integrated environment made famous in the DOS world by Borland's Turbo Pascal and Turbo C. Laser C was the first for the ST, and with features like the Laser DB debugger, it will continue to lead the pack.
Compared to the DOS packages, like Turbo C and Quick C, the Laser C 2.0 package with Laser DB still falls short in a few areas. The flow from editing to compiling to debugging is not as smooth as in the DOS packages. Laser C still has to load each module separately, either from disk or from the disk cache, and Laser DB is, for the most part, a separate entity. For example, in Microsoft's Quick C, one can single-step through a program and edit the source code as soon as a change is required. With Laser C, you have to exit Laser DB, make the changes, recompile, then run Laser DB again. Considering the relatively small size of Laser DB (about 100K) compared to the Laser DB shell (160K) and the amount of code that must be common to both, I don't see why the debugging features of Laser DB couldn't be integrated into the shell. Of course, a stand-alone version of Laser DB is still necessary for those situations where memory is tight.
I recommend Laser C 2.0 to anyone interested in developing software on the ST. However, I'm not jumping up and down with joy and delight as I did when I first reviewed Laser C, simply because the new enhancements do not warrant the 2.0 name. Until Laser C starts to support the ANSI C standard, this latest version is a 1.2 at best, and only because of the improvements in the resource editor.
Laser DB is another story, though. Compared to the other debuggers available on the ST, it is clearly the best. Also, its ability to debug not only Laser C code but also code generated by other C packages and assemblers should make it a welcome addition to any developer's library.
The package of Laser C and Laser DB is very complete. It includes an editor, compiler, linker, resource editor, make utility, disassembler, various utilities cloned from UNIX, a command-line interface, a source-level debugger and GEM/VDI and BIOS/GEMDOS documentation. About all that is sorely missing is a good code optimizer, although Laser C's is still one of the fastest.
Darek Mihocka is a computer engineering student at the University of Waterloo. His latest ST project is the improved ST Xformer, and he is currently working on image-processing and character-recognition software.