Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!gatech!udel!rochester!cornell!batcomputer!braner From: braner@batcomputer.tn.cornell.edu (braner) Newsgroups: comp.sys.atari.st Subject: Re: Laser C Message-ID: <3882@batcomputer.tn.cornell.edu> Date: 29 Feb 88 00:41:34 GMT References: <713@hhb.UUCP> Reply-To: braner@tcgould.tn.cornell.edu (braner) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 89 Keywords: now shipping Summary: first impressions [] I finally sat down and tried out the new Laser C (Megamax 2.0). First I installed it on the hard disk. One main file refused to copy at first, I had to try several times. Bad diskette? The graphical shell will take getting used to but seems rather nice: much better than the desktop, and includes some commmand-line features. A main point of frustration for me is that command lines must be terminated by ENTER, not RETURN. I guess that's for safety, since one can enter a command line from an editor window. But in the "STDIO" window pressing RETURN is just second nature to me. On the other hand, one can go back (even scroll the window back!) to a former command, put the cursor at the end of the line, and press ENTER. One can even select (by dragging the mouse) a block of lines, press return, and (ta-da!) it is like a shell script (alas without conditionals, etc). The shell includes installation of system tools as resident in RAM, and a disk cache with write-through optional separately for each tool. The compiler and linker work very fast if they are in RAM and their output is NOT write-through. That's how the 4-second turn-around time is achieved. (That's right: if you edit a small program in an editor window, and press Control-R, you get the output of the program in about 4 seconds!) One can opt for saving of the source before compilation, just in case. When one quits from the shell all non-deleted not-written-through output is flushed to disk. But first the "cache management" dialog is activated, where one can decide delete some files (e.g., *.o) from the cache so they will NOT be written to disk. A bit of snooping with the supplied disassembler shows: - block initialized data: no more element-by element copying when one codes "static int a[] = {1,2,3,4,5,6,7,8};". - FP ops (as in "double a,b,c; a=b+c;") are done like this: move b-->fpreg0 (two move.l's) pea c pea fpreg0 jsr doubleadd <--- no more dispatcher nonsense (push opcode, call central...) The very fast turnaround time means simple benchmarks are very easy to do. Here are some DOUBLE FP times, in MICROSECONDS (millionths of a second): dabs 60 <--- they don't call it fabs :-( add/sub 160 mul 250 div 320 sqrt 1800 exp 2300 log 2800 (These times include a complete C statement including assignment of the results, e.g., "double a,b,c; a=b+c;".) I believe these are pretty good results for SW FP on an 8MHz 68000. I havn't tried the Savage benchmark right now but when Megamax sent me a prerelease of the new FP package it was faster---and more accurate---than Absoft FORTRAN, which fits with the above results. Other things I noticed in my first session with Laser C: - The supplied "cat" utility displays text with the newlines missing, i.e., as one long line. This is true even for text files created with their editor! - My utility "MORE.TTP" does not work right when invoked from inside the shell (using "tos more filename"). It reports a "TOS error", meaning the file was not found. I suspect the shell passes command-line args to the program in a nonstandard way: MORE.TTP was written in AL and examines the basepage directly. Other .TTP programs I tried (e.g., my version of microEMACS) read the args fine. Any ideas? - Text in the shell's windows is drawn and scrolled VERY fast, especially given that these are standard GEM windows (at least they appear to be, with scroll bars, resizeable, etc). - When I run microEMACS from inside the shell, it reads long text files much more slowly than it does when invoked from the desktop. E.g., a 25K C source file takes about 3 seconds outside, 6 seconds inside the Laser C shell. The only reason I can think of is that the cache is not very fast and gets in the way. (Those times are from the hard disk.) #include - Moshe Braner PS: trying to run UNITERM from INSIDE the Laser C shell resulted in a crash that was too much even for that shell's exception-trapping facilities!