Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!cit-vax!elroy!smeagol!jplgodo!steve
From: steve@jplgodo.UUCP (Steve Schlaifer x43171 301/167)
Newsgroups: comp.lang.forth
Subject: Re: TIL design topics
Message-ID: <854@jplgodo.UUCP>
Date: Mon, 17-Nov-86 14:20:12 EST
Article-I.D.: jplgodo.854
Posted: Mon Nov 17 14:20:12 1986
Date-Received: Mon, 17-Nov-86 21:55:21 EST
References: <1001@usl.UUCP>
Organization: Jet Propulsion Labs, Pasadena, CA
Lines: 81
Keywords: implementation threading

In article <1001@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) writes:
> [....]
> 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 have implemented Forth on both the Apple //e and the Apple //GS and
used subroutine threading in both cases.  It makes the code run a *lot*
faster when you don't have such goodies as auto-increment indexed indirect
addressing modes.  It does mean that some code which was written
for indirect threaded implementations may have to be reworked somewhat.
In particular, words like ',' are sometimes used to compile a 16 bit value
and sometimes an address of a word to be run.  In the first case, you will
probably want to continue to compile the 16-bit value in, but in the 
second you will need to compile the 24 bit JSR.  I built a word called 'J,'
which compiles a JSR to the top of stack value and left ',' to just compile
the 16 bit value off of the top of stack.

> 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 of the handier features of subroutine threading.  It allows
sequences of high level code to be optimized so that

	R> DROP		( drop the top value from the return stack )

can become the machine code

	PLA PLA

if you use the 6502 stack for the return stack.

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

If you run the links from first to last rather than the normal last to first,
then you will not be able to redefine existing words.  A better way to speed
the dictionary search is either to hash the names or use fixed length names.
One scheme for the latter is to keep the first three and the last character
of a name.  I don't like using short names but know of implementations where
it is done that way (it also can save memory).  You could also redefine
the most commonly used words so that they appear near the end of the
dictionary and would be found quicker but at some cost in memory.  I.e. after
the system is booted up, make new definitions for '@', '!', etc. and save the
resulting dictionary for future use.

> [....]
> And a file-oriented system. Screens are the pits. 
> [....]

My Apple //e implementation used screens.  Screens are simple, easy to
implement and easy to understand.  My main objection to them on the Apple
was that the trailing blanks on each line took up space on the disk and
the //e disks are very small (143K bytes).  My //GS implementation uses
ProDOS files and the supplied operating system for access to the disk for
the reasons you give..I don't want to build the device drivers myself,
better use of the disk space, longer files.
-- 

...smeagol\			Steve Schlaifer
......wlbr->!jplgodo!steve	Advance Projects Group, Jet Propulsion Labs
....logico/			4800 Oak Grove Drive, M/S 301/165
				Pasadena, California, 91109
					+1 818 354 3171