[A92] Re: Forth-92

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

[A92] Re: Forth-92


Cliff

      Pocket Forth is/was nice.

      Now here is where I speak from some ignorance - I am not at all 
sure how the 92+ handles memory allocation, However, what you 
describe below was the more or less standard technique one used to 
write a Forth where the OS normally did a reallocation every launch. 
So it does work (smile) for some machines. The idea was to write the 
basic complier/interpreter, some of the things for which speed was 
necessary, and some offset tables, etc. in the lower 64K allocation. 
Then at launch you filled in the offset tables, jumped to the start 
of the dictionary, and began the outer loop. As words are added the 
upper 64K allocation (for Pocket Forth this may be where the 32K 
comes from) is filled - a save saved the entire 64K. For some speed, 
otherwise interpretation drags a bit, you could also create/use a 
hash table at startup - this would not be part of the 64K. Once you 
had a program running in some reasonable fashion, target compilation 
was a possibility which basically removed all of the dictionary you 
didn't need and the interpretation - basically better than 
incremental compilation.
   Perhaps I should add that one can certainly write machine code and 
execute it within a Forth program - it is essentially insulated by a 
header and a trailer which links it up to the dictionary and 
interpreter. So a good Forth would enable one to crash the 92+ in 
undreamed of ways (smile). I can't imagine anything better.

   Anyway what you suggest seems like a good way to go and, barring 
peculiarities of the 92+, should work.

Ed Wall

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