[A92] Re: Forth-92

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

[A92] Re: Forth-92



>       Pocket Forth is/was nice.

Excellent.  The author was/is at a community college I've attended, so 
maybe I can talk him out of at least a bit of source (for educational 
purposes).

>       Now here is where I speak from some ignorance - I am not at all
>sure how the 92+ handles memory allocation.

Pretty standard.  You ask for a block on the heap, it gives you a two-byte 
handle, and you can then use that two-byte handle to get to the block until 
you later free it up.  This is how everything from dynamic allocation 
within programs to file I/O works.  (Having the only file system in RAM is 
kind of nice from that point of view--same function calls to do practically 
anything.)

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

Groovy.  It -felt- like it should work.
I've since done a bit of research on the M68K and discovered that it has 
addressing modes that are simply -perfect- for this.  (Namely, you can 
address using a base address register, an offset in a data register--which 
can be 32bit--and an additional eight bit offset.)  So I'm not limited by 
the -hardware- to 16-bit offset addresses, but I may limit the code to use 
them to cut the dictionary size in half.

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

A step beyond that, of course, would be a simple word that traces every 
word down to the one-or-more fragments of machine code, and simply inlines 
them to make all the top-level words pure machine code.  I'm sure there are 
Forth systems out there with this capability (my reference dates to 1981, 
and this isn't mentioned--but it's also a beginner's guide).

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

*grin*  That's both good and bad. :-)
I'd like to make it rather difficult to crash the machine using straight 
high-level Forth--though if you go batty with memory stores and loads you 
can crash any machine.  But I'd like to have machine code segments an 
option, particularly since they're so damn easy in Forth (you simply define 
words for each opcode, which when compiled generate the machine code).

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

Groovy.  I don't see any 92+-specific issues with it, though I may come 
across 'em.  The main problem I'm dealing with now is that TIGCC's output 
is totally inappropriate for building a Forth, and I'm having to code by 
hand, which I haven't done in years.  (Could always be worse.  My father 
tells stories of -assembling- Forth by hand into core on baggage handling 
control systems. :-)

Cliff Biffle
Follow-Ups: References: