Xref: utzoo comp.sys.mac:17910 comp.sys.mac.programmer:1538 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!jwhitnell From: jwhitnell@cup.portal.com Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: LightspeedC 3.0 Review (long) Message-ID: <7215@cup.portal.com> Date: 9 Jul 88 05:00:25 GMT Organization: The Portal System (TM) Lines: 191 XPortal-User-Id: 1.1001.3098 A Review of THINK's LightspeedC(TM) 3.0 By Jerry Whitnell July 8, 1988 Copyright 1988 by Jerry Whitnell All rights reserved. I just received my copy of THINK's LightspeedC Version 3.0 and after playing with it for a several hours will attempt to review it. I bought the original LightspeedC Version 1.0 at the San Francisco MacWorld where it was introduced, so I have some experience with the product. I will assume you are familiar with LightspeedC and so will comment only on what's changed between Version 2.15 and Version 3.00. Note this is not the upgrade (which I ordered but havn't received), but a copy I ordered from MacConnection (Overnight for $95+$3, ordered yesterday received today). I won't make any more comments about that mostly because, even on the relativly liberal policys of the account I'm using, any comments I made would get me tossed off :-). The Packaging LightspeedC comes in a real box, unlike the shrink-wrapped manual that delivered 2.15. Inside are two disks (800K), two manuals and various pieces of product literature from Symantec. The two manuals are much smaller then then the original 8 1/2 by 11 manual. Much of the material is from the original manual or the 2.03 addendum, but there is also alot of new material as well. The first manual is the User's Manual and describes both the integrated Compiler/Editor and the Source-Level Debugger, while the second is dedicated to the Standard I/O Library supplied for UNIX(TM) compatibility. The Compiler/Editor The Editor portion of the compiler appears to be completely unchanged from the 2.15 version. The compiler, however has many useful changes. The most obvious are those for the source-level debugger. By setting a checked menu option (or in the options dialog box) you can tell the compiler to generate the information the source-level debugger needs to run your program. When you do this, a little bug appears by the word Name in the project window (NO! not more bugs in my program!) and each .c file in the list has a little diamond placed by it's name in the project window. By clicking on the diamond you can enable/disable symbol table information for that file. This is useful to save room on your disk, since the symbol table information can double the size of your project file (270K to almost 600K in my case). The Options Dialog has undergone major surgery to reflect changes to the compiler. Options are now stored in the Project, rather then in LSC itself, but you can specify the default options for any new Project. The options that are new since 2.15 are in the area of code generation, precompiled headers and, of course, the debugger. You can specify that the generated code use 68020 instructions, '881 instructions (or both), in which case the code will only work on those processors. There is one precompiled header (called MacHeaders) that you can have LSC load before each file. This speeds up the compile since LSC doesn't have to reread the .h files from the disk for every file. The default MacHeaders comes with a subset of the Macintosh Include files, however you can also precompile a new MacHeaders to include the rest of the Macintosh header files, the standard I/O Header files or your own common header files. Finally, one can specify whether to include the strings in the DATA resource or (as in 2.15) include them in a separate STRS resource. Including it in the DATA resource allows smaller code since the strings can be referenced off of A5, but limits the total strings+data to be 32K. Leaving the strings in the STRS resource allows you unlimited strings (but still only 32K of data), but you pay the price of larger code. I'll comment on the debugger options when I describe the debugger. The Project Type Dialog box has also received many new fields. From it, you can now control the MultiFinder flags and default size fields for your application. If you are building a Desk Accessory or Driver, you can specify you want it multi-segment and set the flags as well. Finally for the code resources, you can also specify the attributes and whether you want to use the default header or add one of your own. Other minor changes include "Smart Linking" is now an option during the link program phase, selected by a check box in the Save File SF dialog. The other feature that didn't change was the inline assembler. A major lack for 3.0 is the lack of support for 68020, 68881 and 68851 assembly instructions. A slightly less major lack is a Print All commands to match the Save All and Close All. The compiler itself seems to be slower then the 2.15 compiles. Even with the source level debugger turned off, the compiler ran 3 to 4 thousand lines/second slower then the 2.15 version. Rebuild the project with LSC 3.0 (instead of using an imported 2.15) helps alot, but it is still not as fast. Overall compile times are faster due to removal of all the extra .h files the MacHeaders replaced. My tests showed about a 25% improvement, your mileage may vary. The Debugger And now, the moment you all have been waiting for... Once you've selected the debugger option and recompiled all your files, all you have to do is select Run and up pops the LightspeedC Debugger. But don't forget to load MultiFinder, otherwise your program will run without the debugger. When you Run your Project, LightspeedC finds and launches both your program and the debugger. Control is given to the debugger, and it puts up two windows and several menus. The window on the left is the source code window and will display the first page of text of your program. The right-hand window is the data window, more on it in a moment. The text window is a standard text display window with scroll bars, but several extra features. Down the left hand side is a black arrow which points at next C source statement to be executed. Between the arrow and the left hand side of the window are a column of open diamonds. These represent executable statements, statements that generate no code (such as declarations and comments) have no diamond next to them. In the bottom left-hand corner is the name of the current function the text comes from. Across the top are a row of square buttons that control program execution. These are Go, Step, In, Out, Trace and Stop. Go tells your program to take off and run, Trace steps one source statement, In steps into a function (as does Trace), Out will return from the current function to the caller and Step steps over function calls, stopping at the next source statement after the function. You can go into Auto-step or Auto-Trace by holding down the Command or Option key and clicking on the Trace or Step buttons. This will cause your program to continue updating the debugger window while executing until you click the Stop button or Command-Shift-Period. You can click on the diamonds (turning them black) which will cause the program to stop executing when it reaches the statement the diamond marks. You can set as many breakpoints as you want by clicking diamonds. You can also set a temporary breakpoint by holding down the Command or Option key when clicking the diamond. This temporary breakpoint will be removed when any breakpoint (either the temporary or a permanent one) is reached. The data window lets you display the value of any C expression except those that have side effects in any of several formats. Simple objects such as ints, longs and pointers can be displayed as numbers, characters or (for pointers) strings. Structs, arrays and unions are identified by indicators (struct, [], and union) and the address of the object. Double clicking on the data portion will bring up a separate window that displays the fields of the structure. You can repeat this ad nasum or until memory in the debugger runs out. One nice feature is that you can case types (just like real C) so you can display data using different types. Another nice feature is it knows all the preprocessor symbols as well as the C symbols. Finally, by default the values of each expression are updated on entry to the debugger. However you can place a lock on an expression which prevents the value from being updated. This is useful to watch how a value changes because of some operation or function. One features combines the data windows and the breakpoint window. By selecting a statement in the text window and an expression in the data window one can make a conditional breakpoint that breaks only when the expression evaluates to non-zero. Otherwise your program keeps executing. Finally there is some limited communication between LSC (which is still executing) and the debugger. By selecting a menu option in the debugger, you can bring up the file you are executing from in a LSC editor window and edit it. Similarly, you can select a file in the LSC project and return to the debugger bringing it up in the text window. This latter is a clumsy but useful way to set breakpoints in a file other then the one you are executing. You can (via the Monitor command) also enter low-level debugger such as TMON or MACSBUG. LSC still comes with MACSBUG, but they removed the section in the manual on it so you're on your own. Finally if you fortunate enough to have both a Mac II and a second monitor, you optionally tell the debugger to bring up the windows on the second screen. All-in-all, I have mixed feelings about the debugger. There are lots of useful features in it, but I have lots of nits to pick with the user interface. For example, as mentioned above, there is only one text window and to bring up the text from other files you must go back to LSC (unless you execute code from that file in which case it is automatically displayed in the text window). And while multiple data windows are allowed, only the original one can have data entered into it. The others only display the fields of structures that you have opened. And while there is a Windows menu, the only two windows that you can select from it are the two original windows! If you open another to display the fields of a structure, it doesn't get added. Get enough windows and things get hard to find. Finally, I can't resist playing arm-chair quarterback and wonder why the debugger is a separate application and not integrated with the editor/compiler. It seems the current design leads to kludges and lots of wasted memory. However the system works well together and in spite of the criticisms it does a good job of helping debug your programs. And one nice feature is that it is guaranteed to make any user of Microsoft's QuickC or Borland's TurboC eat their heart out. -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell