Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!batcomputer!braner
From: braner@batcomputer.tn.cornell.edu (braner)
Newsgroups: comp.lang.forth
Subject: Re: TIL design topics
Message-ID: <1522@batcomputer.tn.cornell.edu>
Date: Mon, 17-Nov-86 13:27:07 EST
Article-I.D.: batcompu.1522
Posted: Mon Nov 17 13:27:07 1986
Date-Received: Tue, 18-Nov-86 08:52:27 EST
References: <1001@usl.UUCP> <12188@watnot.UUCP>
Reply-To: braner@batcomputer.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 37
Keywords: Roll Your Own Language
Summary: mixing tokens and assembly is possible

[]

In a 6502 Forth I've used ("microSpeed" on the Apple II) a compiled
Forth word is callable from AL, even though it is NOT subroutine threaded.
A pure Forth word starts with "JSR interpret" which jumps to the routine
that (using the address on the stack as a pointer) looks at the (16-bit)
tokens coming after the JSR and does a JSR to each in turn.  The last token
(actually address) in the word is the address of "NEXT" which knows how to 
backtrack this recursion.  AL words end with a JMP to a different version
of NEXT.  In that system there is no way to mix AL and Forth easily in one
word, but it could be easily extended to have an address the AL could JSR
to to switch to Forth for the rest of the word, and a token that would
switch to AL from Forth.

My measurments do show, however, that with the 6502 a JSR-threaded method
IS faster.  I have since moved to the 68000, on which a 16-bit displacement
as a token should be a lot faster, but alas I'm not using Forth right now.

How about modifying Forth by splitting the data stack into two: one for
data (16 bits wide) and one for addresses (32 bits wide on a 68000).
Then you can get rid of a lot of the "noise" words such as '@', if you
construct data structures right.  Also a lot of the extra SWAPs and such
needed to manipulate data and addresses on one stack are eliminated.
For speed, I suggest using very short stacks and keeping them in registers!
(e.g. data stack 4 deep, address stack 2 deep - easily done on the 68000,
leaving lotsa registers free even after you use two as stack pointers
and another as return-stack pointer).  Admittedly, that is NOT Forth anymore!
You would have to use explicit variables a lot more (due to the short
stacks).  But it would be more readable and a lot faster!  Forth was designed
for the hardware of the Seventies, and there is no reason to stick to all
of its details forever.  In this sense I agree that "screens" are obsolete,
especially when you are writing a language for a machine which already has
a traditional OS complete with "files".  In that case there is no penalty
for using what's already there (sometimes in ROM!) and there is an advantage
in making Forth's text files compatible with other uses of the machine.

- Moshe Braner,   Cornell University