jwhitnell@cup.portal.com (07/09/88)
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
jmunkki@santra.HUT.FI (Juri Munkki) (07/14/88)
In article <7215@cup.portal.com> jwhitnell@cup.portal.com writes: >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... WHY?????? It would have been so easy to add and I was planning on writing a lot of 68881 code as soon as I got the compiler. Now I have to trust your FP routines and forget hand-optimization of some stuff. I can probably forget my plans to write any decent 3d-stuff. I don't care that much about the 020-stuff or the 851 instructions (would have been nice though), but the is really a major lack in the assembler. Even the Mach assembler knows 020 and 881 instructions. I hope there will be a 3.01 version real soon. (Well, I'll probably get the $check for the upgrade today anyway...) I like C, but nothing beats 10% asm, 90% C programming. Juri Munkki jmunkki@santra.hut.fi jmunkki@fingate.bitnet
singer@endor.harvard.edu (Rich Siegel) (07/18/88)
In article <14534@santra.UUCP> jmunkki@santra.UUCP (Juri Munkki) writes: [Miscellaneous griping about the missing '881 inline support] It's not so terrible as all that. I agree that the lack of FPCP opcodes in the inline assembler is a deficiency, but between the inline generation of the normal arithmetic opcodes and the high-performance library ("Math881") that I wrote ( :-] ) you'll find that your code is plenty fast. >I like C, but nothing beats 10% asm, 90% C programming. I guess so; actually, my code is 95% Pascal, 5% C... --Rich
ech@poseidon.UUCP (Edward C Horvath) (07/19/88)
> ...but between the inline generation > of the normal arithmetic opcodes and the high-performance library ("Math881") > that I wrote ( :-] ) you'll find that your code is plenty fast. That's it, Rich, I'm calling you out: has it ever occurred to you that pushing arguments onto the stack, doing a jsr, transferring arguments to the FP regs, doing an F-trap, pulling the result back from the FP regs, doing an rts, and popping the arguments off the stack is a bit more costly than JUST DOING THE F-TRAP? Plenty fast? Perhaps. Fast enough? As fast as it COULD be? Not even close. Try running some benchmarks. Shall we race my inline code against your libraries for, say, a month's salary? =Ned Horvath= "Dare to risk confusion by the facts."
awd@dbase.UUCP (Alastair Dallas) (07/19/88)
If you want to put inline assembler in your C programs, can't you just hand-assemble the bytes to define bytes and include them, instead? Or use the C preprocessor to define your bytes with mnemonics, then initialize an array using the mnemonics and use inline assembler to execute the array. It seems to me this should be an acceptable solution unless what you really want is a .rel file assembly language glue-code library. :-) /alastair/
singer@endor.harvard.edu (Rich Siegel) (07/20/88)
In article <455@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes: >Plenty fast? Perhaps. Fast enough? As fast as it COULD be? Not even close. Suppose you read my post again? I DID NOT say that the current scheme is the fastest; it is, however, faster than using SANE. >Try running some benchmarks. Shall we race my inline code against your >libraries for, say, a month's salary? If you want. If you win, you lose.;-) To repeat: we KNOW that it's a deficiency; there just wasn't enough time to get all the features in, and this one didn't make it. There will be future versions of LightspeedC, after all... --Rich
kah120@ihlpe.ATT.COM (Ken Heitke) (07/20/88)
In article <4984@husc6.harvard.edu>, singer@endor.harvard.edu (Rich Siegel) writes: > In article <455@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes: > >Plenty fast? Perhaps. Fast enough? As fast as it COULD be? Not even close. > > Suppose you read my post again? I DID NOT say that the current scheme > is the fastest; it is, however, faster than using SANE. > First I would just like to state that I have been reading the net for quite awhile and feel Rich provides us with a valuable service. This is after all what he gets paid to do. But, I think he has been getting a little cocky lately with his responses. Basically Rich, I think you are talking down to you customers as if you were a superior. When it comes to customer support this is a definate no no. The customer is always right and should be treated with respect. Now I understand that you should be able to have dialogs as you see fit but I think on discussions in which you are representing your company's product you should be a little more careful. If Mr Horvath misunderstood your posting then maybe, just maybe, you weren't making yourself clear. Ken Heitke att!iwtio!kah
dan@Apple.COM (Dan Allen) (07/22/88)
In article <3169@ihlpe.ATT.COM> kah120@ihlpe.ATT.COM (Ken Heitke) writes: >First I would just like to state that I have been reading the net for quite >awhile and feel Rich provides us with a valuable service. This is after >all what he gets paid to do. But, I think he has been getting a little >cocky lately with his responses. Basically Rich, I think you are talking down Rich does NOT get paid to answer net mail as I understand things. He works testing Think's software for robustness. He, like many of us, answers net mail out of the goodness of his heart. After answering enough net mail as a continuous stream of complaints, we all tend to break under the stress and perhaps we do get a bit cocky. The solution to the problem is for people to be a bit more polite to Rich and not hassle him so much. I stress this because I am somewhat in the same situation here at Apple. So is Larry Rosenstein. We all would like to help people with their questions whenever possible, but we DO have work to do. So I'll get back to work on HyperCard 2.0 and hope that this group can spend more time on the technical issues and not spend so much time hassling each other. Dan Allen Software Explorer Apple Computer
singer@endor.harvard.edu (Rich Siegel) (07/22/88)
In article <14445@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >In article <3169@ihlpe.ATT.COM> kah120@ihlpe.ATT.COM (Ken Heitke) writes: >>First I would just like to state that I have been reading the net for quite >>awhile and feel Rich provides us with a valuable service. This is after >>all what he gets paid to do. But, I think he has been getting a little >>cocky lately with his responses. Basically Rich, I think you are talking down > >Rich does NOT get paid to answer net mail as I understand things. He >works testing Think's software for robustness. He, like many of us, >answers net mail out of the goodness of his heart. After answering >enough net mail as a continuous stream of complaints, we all tend to >break under the stress and perhaps we do get a bit cocky. The solution >to the problem is for people to be a bit more polite to Rich and not >hassle him so much. Thanks. I hadn't read this post the first time it circulated, so I didn't see the assertion that I was paid to read the nets. THIS IS NOT TRUE. I do not get paid to answer phones or read net mail. No one here at THINK does, although between us, we cover Usenet, Info-Mac, and CIS. This is a service that we provide, free of charge, on our own time. As Dan said, the situation is the same with me as it is with him. >So is Larry Rosenstein. We all would like to help people with their >questions whenever possible, but we DO have work to do. So I'll get >back to work on HyperCard 2.0 and hope that this group can spend more >time on the technical issues and not spend so much time hassling each >other. And I'll get back to work on Lightspeed Pascal 2.0 and spend less time putting up with this <expletive deleted>. --ich Rich Siegel THINK Technologies Rich Siegel Quality Assurance Technician THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305
ech@poseidon.UUCP (Edward C Horvath) (07/22/88)
> Xref: poseidon comp.sys.mac:18869 comp.sys.mac.programmer:1504 > If you want to put inline assembler in your C programs, can't you just > hand-assemble the bytes to define bytes and include them, instead? Or > use the C preprocessor to define your bytes with mnemonics, then initialize > an array using the mnemonics and use inline assembler to execute the array. "Tell me what you need, I'll tell you how to live without it." While what you suggest will work, there is very little reason for the mnemonics to be missing from the assembler. Most assemblers are table-driven: adding new mnemonics is fairly straightforward (once you have done it once!). I'd class this as an oversight and expect Think to correct it in 3.0x. =Ned=
ech@poseidon.UUCP (Edward C Horvath) (07/23/88)
> Xref: poseidon comp.sys.mac:18934 comp.sys.mac.programmer:1520 > Suppose you read my post again? I DID NOT say that the current scheme > is the fastest; it is, however, faster than using SANE. > --Rich The original article asked, "why no inline '881?' and your response said, "because you don't need it." Rich, I LIKE the product. But your attitude about LSC has increasingly been one of "anything left out is not important," and it is that attitude which I object to. When people ask for things that were left out, TELL YOUR DEVELOPERS. There is never enough time to do everything, but the feedback YOU provide the developers helps them build the product features the customers most want to see. =Ned=
jmunkki@santra.HUT.FI (Juri Munkki) (07/24/88)
In article <419@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >If you want to put inline assembler in your C programs, can't you just >hand-assemble the bytes to define bytes and include them, instead? Or Would you do this? I don't think you would. Since an inline assembler is relatively easy to write and adding 68881 instructions would probably have involved changing code so that it handles FP constants and registers (no new addressing modes) and then making a few additions to a table of commands (I assume that the ASM mnemonics are stored this way). The worst problem would probably have been testing. You have to test every possible command and combination to verify that the code is correct. You also have to have some pretty advanced beta testers for stuff like this. I still hope there will soon be a new release with an improved asm. I also hope it will be distributed either for free or through computer networks as an upgrade program. Juri Munkki | (,: jmunkki@santra.hut.fi | Maybe some day: (,; jmunkki@fingate.bitnet | jmunkki@pizza.hut.fi {,: P.S. Has anyone thought of user-extensible compilers?
beard@ux1.lbl.gov (Patrick C Beard) (07/28/88)
This is in response to the original posting that griped about the lack of 68881 inline assembler. Well, I think the inclusion of a .o converter with the 3.0 release really makes the difference. I use the MPW assembler to do floating point stuff so the ability to link in code from it fills in the gap until Think/Symantec/Michael get with it. Keep it up guys! Patrick Beard PCBeard@lbl.gov (arpa)