Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!rutgers!clyde!burl!codas!akgua!usl!elg
From: elg@usl.UUCP (Eric Lee Green)
Newsgroups: comp.lang.forth
Subject: TIL design topics
Message-ID: <1001@usl.UUCP>
Date: Fri, 14-Nov-86 14:45:57 EST
Article-I.D.: usl.1001
Posted: Fri Nov 14 14:45:57 1986
Date-Received: Sun, 16-Nov-86 00:12:15 EST
Reply-To: elg@usl.UUCP (Eric Lee Green)
Organization: USL, Lafayette, La.
Lines: 67
Keywords: Roll Your Own Language

Velcome, forthfans.

I am currently designing a small threaded language in which to program
my fairly new Commodore 128. I don't particularly like FORTH, it is
excruciatingly slow on a 6502, and the command names are just aweful
(comeon now, "!"? "."? ":"? Gimme a break!). But I do like the general
FORTH idea. So, I'm looking for comments on these implementation
decisions:

subroutine-threaded: Instead of threads being two-byte machine
addresses, have a jsr <address> machine instruction instead. Immediate
advantage is speed (NEXT is very slow on a 6502), at a cost of making
the program 3/2 larger. The largest FORTH I've ever seen for the 6502
was only 25K. My C-128 has 128K of RAM. Space is hardly a problem.

I noticed an additional goodie about subroutine threading -- you can
put assembly language code in the same procedure as regular code, and
you can call regular TIL words from within your assembly language
subroutines. This is one step further toward the goal of being able to
write your program completely in the TIL, then come back and re-write
critical routines and critical parts of routines in assembly language
to get the required speed. 

Reversing the links: In most FORTH systems, the "compiler" or
"interpreter" (threader?) starts searching for words starting at the
last word defines, and runs down the link till reaching the bottom or
finding the word. The most-used words, like "@" and "!", though, are
defined close to the bottom of the text stack.  So why not start at
the bottom, and go upwards? In Superforth-64, it sometimes takes 10
seconds to compile a block after reading it in from disk (which is
tediously slow in itself, with the notorious 1541 drive). Probably due
to the fact that it has some 250-300 words in its vocabulary.

But, what side effects will that have? Surely, there is SOME reason
that FORTH systems usually have the links going the wrong way!

Those are the major implementation questions. Now for a quick rundown
of some of the other features I'm considering:

Dynamic string handling a' la' BASIC, along with a seperate string
stack. I have the garbage collector designed, and it is very time
efficient, at the cost of being a bit space-inefficient (a string
variable consisists of a length, address, and link -- 5 bytes). Since
the application I have in mind is very string-intensive, this was a
very important feature to have.

And a simple module structure, somewhat like Forth "vocabularies",
	except with better syntax.
And a method of doing overlays, easily.
And array declaration and access words.... 

And a file-oriented system. Screens are the pits. The designer of
whatever hard drive etc. that I'm using has already gone to a bunch of
trouble making a compatible DOS driver, it's really a drag to have to
write a FORTH driver for that drive myself when the DOS driver is
sitting there... I have a SFD-1001 disk drive that I cannot use with
Superforth-64 simply because I do not have time or inclination to go
in and critically mangle the screens code. Not to mention that having
to cram all of your code into 16 lines of 64 characters tends to make
you omit comments and otherwise use poor style...
-- 

      Eric Green {akgua,ut-sally}!usl!elg, elg%usl.CSNET
        (Snail Mail P.O. Box 92191, Lafayette, LA 70509)

" In the beginning the Universe was created. This has made a lot of
 people very angry and been widely regarded as a bad move."