[A92] Re: Forth-92

[Prev][Next][Index][Thread]

[A92] Re: Forth-92



I've already completed an ANS Forth System for the TI-92/Fargo. I'm not
satisfied with some parts in it, that's why I wanted to rework some things
before release. I unfortunately don't have much time, and since interest
in the TI-92 has decreased quite a lot, and I do not own a TI-92+ or
TI-89, I currently don't spend much time at it.

If you're interested, I can send you the complete source. Btw, I solved
the dictionary problem, by making just every Forth address 16bits and
addressing via a Base pointer eg. 0(BP,d0.w) . This implies, that the
free dictionary space must be part of the Forth system's program itself,
and is thus (at least for Fargo) limited to 32K. But on the other hand,
everything is compiled extremely small. A 32bit Forth system will get
much larger and run only half the speed, due to how the 68k Processor
handles dwords. Also the 68k does not have 32bit*32bit multiplication,
it'd have to be emulated by 4 mul instructions. 32bit/32bit division would
be even more tricky. I think that emulation via div instructions isn't
even possible, you'll need a manual implementation with 32 bit-shifts,
comparisons and adds.

My Forth system does some crash protection:
  * check whether writes to the dictionary are in the range of the
    user-accessible area (that's a check for 0<=addr<dict_size, can be
    done quickly with the 68k's chk instruction)
  * Check for abort-key-combo in the code that's compiled by loops.
  * Check for stack under/overflows in the code that's compiled by loops,
    added some area to the stack that can safely be under/overflown
    without crashing
And that costs only about 10% speed.

The Forth system I wrote is unfortunately written using a selfmade
CPP like preprocessor. This is quite pratical for writing high-level Forth
code, especially control flow structures. But it's also ugly and not very
portable. A Forth cross compiler would be very, very much nicer. It could
output an object file, that could be linked by `flink' for Fargo, or other
tools (I don't know) for TI-92+/TI-89. Documentations about the object
format (some Amiga thing) can be found at ticalc.org. I also have an 68k
Forth-assembler, that I could send you. 
A cross-compiler could also be used as a portable "high-level" programming
language for TI-92(+)/89 programming, using a PC as host (who'd want to 
use ti-gcc, if a forth compiler is available? ;-)

If you're interested in writing your Forth system as a team-work, please
let me know. I might not have much time, but since you own a TI-92+, that
work might actually be useful.

							David Kuehling

On Sun, 15 Apr 2001, Cliff L. Biffle wrote:

> 
> I've found an implementation of Forth on the 68000 (actually, for the 
> Macintosh, but it's 68K generation) written by a guy about ten miles from 
> me, and I'm going to see if I can sweet-talk some source out of him, if 
> only as an example.
> 
> One of the problems I'm dealing with is that the dictionary is likely to 
> move around in memory quite a bit.  We can't put it at the high end of RAM 
> and lock it (the traditional way of fixing addresses without hurting the 
> heap block compression routines), because then we can't grow the dictionary 
> without manually moving it down in RAM--which changes addresses 
> anyway.  The issue here is that most Forth words are identified by their 
> code addresses, which we don't want to recalculate--every single one--when 
> the dictionary is moved.
> 
> The 68K has a 32-bit-address-plus-16-bit-signed-offset addressing mode, the 
> name of which I can't remember (it's been ages since I've written 
> asm).  This allows one to reference a 64K block around an address, but only 
> 32K in either direction.  So, my solution is this:
> --Obtain the address of the start of the dictionary (using heap handle 
> dereferencing).
> --Add 32768 (the negative range of a signed word) to it.  (Let's call that D)
> --Treat the first cell in the dict as -32768(D), and the last cell (if the 
> dictionary is the full 64K) as 32767(D).
> 
> This offset address D may not necessarily even be a valid RAM address, 
> because the actual RAM available in the TI-whatever is a tiny little sliver 
> of the 68000's address space.  The offsets from D into the file would be 
> constant, and as long as we don't write any really funky execution 
> addresses, we won't be grabbing random bytes from somewhere past the end of 
> RAM.
> 
> I don't know if this would work like I intend it to, or if it's a good 
> idea.  The -other- 68K Forth implementor (creator of Pocket Forth for the 
> Mac) imposed a 32K dictionary size limit, as that was the positive offset 
> range of the pointers.  Either he didn't think of this rather strange 
> solution, or he ruled it out as unwise.
> 
> Thoughts?
> Cliff Biffle
> 
> 
>
Follow-Ups: References: