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