| Good News - I finally received my 3.07 GFA Basic interpreter and the GFA
Basic 3.0 compiler!
It came with a letter restating what they told me in a phone conversation:
that "Due to problems beyone our control, the release date for the
revised GFA BASIC 3.0 manual has been pushed back." In compensation, they
are sending me the new compiler and interpreter free. My check for them
is to be returned. On the phone, they said I will still get the new
manual, when it comes out, but the letter was less clear on the matter.
A friend of mine also ordered the update and compiler, but about a week
after I did. He just found out there will be a delay since they ran out
of updates, due to the "unexpected heavy demand". The delay should be
about 10 days or so.
Anyway, on the disk was a README file, containing update notices. I
extracted the 3.05 to 3.07 changes, and here they are:
============================================================================
-- Changes to GFA BASIC 3.06 and 3.07 --
A 4K buffer is allocated for each open file. This speeds up I/O since
buffers no longer need to be allocated for each read and write.
INPUT now handles commas and CRs correctly when reading files.
Changing between READ and WRITE of files without an intermediary SEEK now
works.
In the editor, typing Tab+LShift inserts blanks to the tab position.
Tab+RShift deletes all blanks to the left of the cursor. If the cursor is on
a blank, it is deleted along with all following blanks
A new command for producing Bezier curves is available:
CURVE x0,y0,x1,y1,x2,y2,x3,y3
A Bezier curve is drawn from (x0,y0) to (x3,y3). The Bezier curve is tangent
to the line segment (x0,y0)-(x1,y1) at (x0,y0) and is tangent to segment
(x3,y3)-(x2,y2) at (x3,y3). Consider the points (x0,y0) and (x3,y3) as
the beginning and end points and (x1,y1) and (x2,y2) as the control
points for the curve.
============================================================================
I haven't tried out these features yet. But I did try to run the 3.07
interpreter. 3 bombs every time, even off disk. Suspicious, I removed the
print spooler accessory from Neodesk, since that had given me trouble in
the past (Gribnif is surprised that the spooler should give any problem).
The interpreter then came up and performed flawlessly.
For my first test, I ran a 36K GFA file. It loads a 400K data file from
hard disk. I use the new TOS 1.4, and the load time is usually 6 seconds.
But with 3.07 it took 9 seconds! I did the test several times to verify
that the newer version was slower on loads, in spite of their new
buffering.
Being impatient to try the new compiler, I only skimmed the compiler
manual. Unlike with the version 2 compiler, there are now lots of options
for compiling and linking. You don't run the compiler directly, but
instead access it via MENU.PRG. Under the File drop down menu, click on
SELECT to select the file to compile, then click on COMPILE to compile
it, and finally click on LINKER to link it. The result is a file called
TEST.PRG, which you rename to whatever you want. There is an option to
make the compiled file root name the same as the input file, but I didn't
read enough to find out how to do that.
The above 36.5K GFA file took 8.6 seconds to compile and 9.2 seconds to
link, creating a 37.7K PRG file. I don't recall the size of the object
file. I think the object library was about 100K. The entire GFA disk was
filled with about 700K of software
Next, I ran the program, and called for the database sort option (using
my version of the QUICKSORT algorithm), comparing the execution time to
that of the 3.05 and 3.07 interpreters. The 3.05 interpreter took 267
seconds, while the 3.07 version took only 228 seconds (the release notes
don't explain this discrepancy, since the sort was in memory, not on
disk). In the compiled program, the sort took 89 seconds, exactly three
times faster than the 3.05 interpreter.
Oh, I should mention that the compiled version exhibited a few "quirks".
One was that the screen was not erased upon startup, as the interpreter
did automatically. The compiler provides a switch to do this, but I
didn't exercise it. Also, the date string is now different in format,
e.g., 04.10.1989 instead of 10/04/1989. This also is controlled by an
option, but an interpreter option. Apparently a default changed. Other
than that, I saw no unexpected differences. The compiled program appeared
to run about three times faster (a welcome improvement!).
In a second program that does lots of disk access and string processing,
the runtime went from 3 minutes, 20 seconds down to 1 minute and 55
seconds. But in both of these trials operation slowed down as the record
count increased to 3500. Its as if some garbage collection was not being
properly done, but that's only speculation.
The compiler has other nice options, such as to force the use of the
68000 MUL statement for multiplies, so that you can really speed your
program up in certain applications. It also explains how to make desk
accessories, but I haven't gotten into that yet.
Oh, finally, the compiler manual quality - much better than usual. I saw
only two small typos in about a dozen pages. The quality of the German to
English translation was excellent also.
So far I'm very happy with it. I'll post any other newsworthy items here
when I uncover them.
|