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/
gillies@p.cs.uiuc.edu (07/19/88)
Recently, Comp.arch listed the results of a Dhrystone test of different C compilers. The results included LightspeedC, at 2467 Dhrystones, and also Sun 3/50's, at as much as 4000+ Dhrystones on a 16.67Mhz 68020 (gcc compiler). So I don't think that LightspeedC is nearly as fast as possible. A better compiler for the same CPU (at 1Mhz more clocks) runs almost 8/5 as fast! Oh well, some day we will have extremely efficient compilers for the macintosh.... I hope.
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
singer@endor.harvard.edu (Rich Siegel) (07/20/88)
In article <76000259@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >Recently, Comp.arch listed the results of a Dhrystone test of >different C compilers. The results included LightspeedC, at 2467 >Dhrystones, and also Sun 3/50's, at as much as 4000+ Dhrystones on a >16.67Mhz 68020 (gcc compiler). So I don't think that LightspeedC is >nearly as fast as possible. A better compiler for the same CPU (at >1Mhz more clocks) runs almost 8/5 as fast! Oh well, some day we will >have extremely efficient compilers for the macintosh.... I hope. I agree that LightspeedC isn't as efficient as possible, but to compare itts execution on a Mac II to GCC's execution on a Sun 3 is unfair, since the two machines have fundamentally different hardware designs. If you want to make a valid comparison, run gcc on a Mac II running A/UX. There's more to a comparison than just saying "The sun 3 has the same CPU as the Mac II, and the same clockk speed (+/- 1MHz), but LightspeedC runs slower on the Mac II, so it must be inferior." --Rich Rich Siegel Symantec/THINK Technologies
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
kennel@minnie.cognet.ucla.edu (Matthew Kennel) (07/21/88)
In article <76000259@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >Recently, Comp.arch listed the results of a Dhrystone test of >different C compilers. The results included LightspeedC, at 2467 >Dhrystones, and also Sun 3/50's, at as much as 4000+ Dhrystones on a >16.67Mhz 68020 (gcc compiler). So I don't think that LightspeedC is >nearly as fast as possible. A better compiler for the same CPU (at >1Mhz more clocks) runs almost 8/5 as fast! Oh well, some day we will >have extremely efficient compilers for the macintosh.... I hope. Yup, GNU CC is _very_ good! And it's free! Is there anybody interested in porting it to the Mac? I suspect there might be a big problem in object file format, etc. Matt Kennel (kennel@cognet.ucla.edu )
dlt@csuna.UUCP (Dave Thompson) (07/21/88)
In article <76000259@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >different C compilers. The results included LightspeedC, at 2467 >Dhrystones Interesting. I get 2941 Dhrystones/sec on Mac II, LSC version 2.15. ( I haven't received version 3 yet.) -- Dave Thompson uucp: {ihnp4|hplabs|psivax}!csun!csuna!dlt CSUN Computer Center phone: (818) 885-2790 18111 Nordhoff Street, Northridge, CA 91330
dtw@f.gp.cs.cmu.edu (Duane Williams) (07/21/88)
In message <3169@ihlpe.ATT.COM>, Ken Heitke writes:
"The customer is always right..."
Aside from straightforward self-contradiction, is anything more obviously
false than this? It MAY (although I doubt it) be a good business practice
to often treat customers AS IF they were right, but that is not to say that
they ARE right.
--
uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw
arpa: dtw@cs.cmu.eduwetter@tybalt.caltech.edu (Pierce T. Wetter) (07/22/88)
> >Yup, GNU CC is _very_ good! And it's free! > >Is there anybody interested in porting it to the Mac? >I suspect there might be a big problem in object file format, etc. > The problems with porting Gnu C are as follows: 1: Add the Pascal keywoard for talking to C programs. i 1a: add the \p escape. 2: Make doubles 80 bits longs (90 for 68881) 3: Richard Stallman thinks Apple is the AntiChrist Problems 1 and 2 are not insurmountable, if you have the time. I have ported bison to MPW already (Gnu's yacc clone). 3: is irrelevant. However, one advantage of porting Gnu CC, besides the fact that its a good compiler, is that a Gnu C++ port is trivial after that. So i'll make someone a deal. They port Gnu CC, and I will give them advice and I will port Gnu C++, and GnuChess. Pierce ---------------------------------------------------------------- wetter@tybalt.caltech.edu Race For Space Grand Prize Winner. ----------------------------------------------------------------- Useless Advice #986: Never sit on a Tack.
shebanow@Apple.COM (Andrew Shebanow) (07/22/88)
It is extremely unfair to compare Lightspeed C 2.0 results on these benchmarks with the gcc compiler on a Sun 3/50: LSC 2.0 did not support 68020/68881 code generation, which explains the difference in benchmark results. LightspeedC 3.0 now supports these options, so the results should be markedly better. MPW 2.0's C compiler is based on Green Hills' gcc compiler, the same one you quoted for your benchmark (I think you meant this one, and not the Gnu one, which is also called gcc). This compiler does most of the advanced optimizations you here about on mainframe compilers. As you might expect, the Sun 3/50 and the Mac II get almost exactly the same numbers when run with the same compiler. Considering that MPW C has been available for quite some time, it is not reasonable to say that optimizing C compilers will show up someday: they've been here for more than a year. Have fun, Andrew Shebanow Macintosh Developer Tech Support Apple Computers PS: never, ever believe any benchmark results. -- Disclaimer: these opinions are my own: Apple Computer is not responsible, and neither am I. --
gillies@p.cs.uiuc.edu (07/22/88)
Here are the relevant statistics from comp.arch:
Model Proc Clock O/S Compiler/Options noReg Reg
---------------------------------------------------------------------------
Mac Plus 68000 7.83 Sys4.2 Lightspeed C 2.15 719 789
Mac Plus 68000 7.83 Sys4.2 Lightspeed Pascal 1.11a 781 781
Mac Plus 68000 7.83 Sys4.2 MPW Pascal 2.0.2 -r [1] 832 832
Mac II 68020 15.67 MultiF Lightspeed C 2.15 2469 2469
AST Premium/286 80286 10 MSDos3.3 Microsoft C 5.10 [2] 3309 3309
Sun 3/260 68020 25.0 SunOS4.5 gcc 1.17 6993 7012
[1] -r [no range check] switch
[2] Betatest compiler, options were -AS/-AC/-AL -Ox, fastest '286 PC tested
Someone said their Mac II achieves 2941 Dhrystones -- that is not bad.
Linear extrapolation indicates that the Sun gcc compiler should attain
4395 Dhrystones on a 15.67 Mhz Mac II. I have heard that the gcc
compiler supposedly does a good job of automatically assigning
variables to registers. Apple's pre-assignment of certain values to
certain registers in the Mac OS no doubt slows down ALL C programs on
the Macintosh, since you are FORCED to preallocate certain registers
for certain purposes.
I refuse to believe that the Mac OS, with no multitasking and very
little overhead, is a significant drag on the CPU (relative to SunOS).
What I wonder is: Does the Sun have a custom cache memory, or is
SunOS inaccurately timing this benchmark, or does Sun main memory cycle
faster than 120ns * 15.67Mhz / 25.0Mhz ?
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gilliesech@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=
kurtzman@pollux.usc.edu (Stephen Kurtzman) (07/23/88)
In article <2330@pt.cs.cmu.edu> dtw@f.gp.cs.cmu.edu (Duane Williams) writes: >In message <3169@ihlpe.ATT.COM>, Ken Heitke writes: > "The customer is always right..." >Aside from straightforward self-contradiction, is anything more obviously >false than this? It MAY (although I doubt it) be a good business practice >to often treat customers AS IF they were right, but that is not to say that >they ARE right. Duane, Ken was pointing out that a person was being snotty and disrespectful. You are right when you say the customer isn't always right. But the sense in which to take the previous posting is that the customer always deserves respect and that his opinions are not necessarily wrong just because they differ from yours. I would go further than this and say that if the customers' opinion differs from yours, you better make every attempt to understand their viewpoint. And if you can't adopt their view, at least respect it. This is especially true in the computer industry where there are many intelligent and talented people around.
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?
rob@uokmax.UUCP (Robert K Shull) (07/26/88)
In article <76000259@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >Dhrystones, and also Sun 3/50's, at as much as 4000+ Dhrystones on a >16.67Mhz 68020 (gcc compiler). So I don't think that LightspeedC is A good example of how much the compiler can affect the results: Using Sun's supplied compiler, the Sun 3/50 here gives a hair over 2000 Dhrystones. Robert -- Robert K. Shull University of Oklahoma, Engineering Computer Network ihnp4!occrsh!uokmax!rob CIS 73765,1254 Delphi RKSHULL Opinions contained herein do not exist, except in your imagination.
cramer%clem@Sun.COM (Sam Cramer) (07/28/88)
In article <1648@uokmax.UUCP> rob@uokmax.UUCP (Robert K Shull) writes: >>Dhrystones, and also Sun 3/50's, at as much as 4000+ Dhrystones on a >>16.67Mhz 68020 (gcc compiler). So I don't think that LightspeedC is > >A good example of how much the compiler can affect the results: > Using Sun's supplied compiler, the Sun 3/50 here gives a hair over >2000 Dhrystones. Using the SunOS 4.0 C compiler, setting optimization to -O4, and linking -Bstatic, I get about 2700 dhrystones/sec. Sam Cramer sun!cramer cramer@sun.com
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)