NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/4017

Text File | 1993-01-28 | 6.1 KB | 143 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!starnine!mikeh
From: [e-mail] (Mike Haas)
Subject: Re: Documenting
Message-ID: <[e-mail]>
Sender: [e-mail] (Mike Haas)
Date: Thu, 28 Jan 1993 05:19:52 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 131

In article <[e-mail]> [e-mail] (Nicolas Tamburri) writes:
>
>What has fanned these flames are
>those who advocate that block are the only way to go, and stream files are an
>abomination to Forth.  (Although I believe it was MH who set fire to it all with
>an incindiary message about how screens should go the way of the dinosaur.
>Apologies beforehand if I'm wrong Mike.)

I believe you're right.  And we've been having fun ever since.

And what a surprise... BLOCK is still in Forth and files, at best,
are optional.  Who'da thunk it?

I understand that BLOCKs will always be in Forth.  In the embedded
controller arena, they are necessary!  (well, at least they seem to
be the simplest answer to the mass-storage problems in such situations.)

And I used them myself for years when I used my homebrew machine
running Fig-Forth.  But my partner and I (it was multi-user) still
found them so abhorent to use that we developed a file system
on top of them.  Anyone could do it... only took a few weeks and
we were doing DIR listings.

(BTW...yes...I can hear it...when was Fig-Forth multi-tasking, much
less multi-user?  Well, the writers of the 6800 Fig-Forth, and
probably all, had included the 3 USER variables you needed
to support multitasking, they just didn't say what they
were for!  One had just to write a task-switcher, creater, etc,
and patch KEY, EMIT & ?TERMINAL to get the old round-robin
multi-tasking!  If you write things correctly, multi-user
was no problem).

Yeah, that file system took nearly 20k of my home-brew 6800 (no,
I didn't forget a '0') system's 64k, but it was never regretted.

I can't express to those who have never made that transition how
much easier software development was!  We never dealt with
SCREEN numbers again!.  We had filenames!

Now we had commands like LOAD-FILE, EDIT-FILE, CREATE-FILE,
DELETE-FILE, RENAME-FILE, COPY-FILE (even between different
volumes!), COMPARE-FILES, GET-FILE-INFO, great stuff!

On a hard-disk, we could CREATE-DIRECTORY at several places,
in effect yielding different partitions, each with it's
own copy of this architecture.

None of this was real complicated, a simple bit-mask block-list (I
think at SCR#10) where we could allocate BLOCKS on the disk from and track
them.  Another area to store the filenames and a few pointers to
things like that file's individual block-list, and whether it was
level 1 or level 2 (using 4 bytes for a pointer, the block-list
could point to the possible 256 screens in the file.  If a file
wanted to larger, the file system would automatically change it to
'level 2'...a 'master' block-list would point to upto 256 block-lists,
each of which could be used to trach 256 BLOCKS of the file.
This gave us a maximum file size of 256x256 BLOCKS or
65 Meg.  This seemed infinite at the time because our largest
hard drive was 5 Meg!).

We later used this 'filename' area to save the files creation &
modification dates, so true incremental backups could be automatically
made by datestamp comparison.

And all our code was ported almost instantly!  We had to change
3 things in any program...

   1. Open the file at the beginning

   2. Replace ever instance of BLOCK with FILE-BLOCK

   3. Close the file when done

(FILE-BLOCK did all the work... it would make sure the
file was big enough, do the logical-file-block# to
physical-screen# conversion, call BLOCK, then return thre
buffer adr)

This opened a world of ease, convienience, organization,
it was incredible how much faster we could develop code.

And this was with just a BLOCK-based file system... the code was still
in SCREENS... it's just that now we could consider SCREENS
45, 80 and 19 to be contiguous...the file system made it so virtually.

It was a simple matter to implement INSERT-FILE-BLOCK, so
forget LOAD-SCREENS!   All of your code was now
maintained in order for you, compiled in order, IT WAS A
SINGLE OBJECT!

Now we could keep little support routines like SQRT in something
called SQRT (instead of knowing it's on SCREEN 267), and when
needed it could be compiled quickly with a simple...

   LOAD-FILE SQRT

And it was no sweat to dump the files logical file-blocks
(non-contiguous screens) to a virgin disk in contigous
fashion, so that anytime, you could revert to the normal
BLOCK environment again. (but we never did)

Anyway, this early experience really sank in, and I've
never used SCREENs in their normal mode again.  I ported
that file system to other Forths... even platform Forths
(the other guy was a CP/M man) and that led to the curious
situation of having files (ours) within screens (the forth's)
within files (C/PM's)!!!


Now the ol' 6800 system gathers dust in a closet, hasn't been
turned on in years.  With JForth and my Amiga, I deal
with real end-of-line terminated files in the powerful
Amiga OS...they are no different than C or Pascal source files
in that I can use any OS utility on them (like diff, type,
copy...anything).  I don't even think a 2cnd thought about it anymore,
except when I, just for grins, INCLUDE the BLOCK environment which
includes the full-screen editor and play around with SCREENS
inside of an Amiga file.  Man, it's wierd to be using screens!

Don't get me wrong... I wrote SCRED (the full-screen editor) and
I'm damn proud of it... any Forth programmer would enjoy
using it... but I never do.  But it's OK, because I also wrote
the editor I use on my JForth files.  And it's a standard
text editor that I sell as shareware and very fancy.  Y'see...
there's a REAL MARKET for STANDARD STUFF!  That makes you want to
make it real fancy... because you have a REAL MARKET...

Oh well, I'm starting to prostilatize (sp??) again.  (I can hear
the shouts... WHEN DID YOU QUIT?).

Ah, nostalgia is good for the soul.