🚀 go-pugleaf

[]

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 <std.disclaimer>

- 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!