Excellent news!
The 6502 STC Forth that I'm working on now runs, albeit very incomplete, under the Commodore 64 emulator.
A number of basic primitives exist -- I implement primitives only as I need them to write the rest of the Forth environment, so as to minimize the need for debugging while maximizing progress. I even wrote my own version of * which does a 16x16=16 multiplication. Amazingly, it worked the first time.
The Forth 'outer interpreter' now works great. I rely on Commodore's kernel for the screen editing capabilities, which makes my text input code utterly trivial. But it's factored enough to let me rewrite the text input code if required. The interpreter itself, however, works like a dream, although it took me a number of days to fix a bug where it would never detect a missing word.
The things that it lacks now include:
* Colon-compiler -- this is the biggest omission. However, implementing this ought not be too terribly difficult now that
most of the words it depends on have been written.
* Word names are still not precisely correct -- because I'm using a cross-compiling environment to develop the software, words are written using commas after their names to distinguish host from target compiled words. This system works *great*, doesn't require the use of a Forth with vocabularies. However, inside the target image, those commas all exist inside the word names, so you still have to use commas there too. For example, to exit the Forth environment, you need to type
GO64, instead of
GO64.
* Because I used commas to distinguish target and host words, there is a conflict between the assembler's AND, instruction and the host Forth word AND,. Therefore, I need to change from the use of commas to the use of ticks (e.g., instead of
AND,, I would use
AND'). As a temporary work-around, I'm currently using
&, to stand for AND,.
* Because of how PETSCII works, I need to capitalize all words in my sources.
* I need to implement loading from blocks, which means I'll also need to implement the generic block I/O words too.
One thing is for sure though -- I should have been writing this with literate programming, as with my Colonel project, so that it could be precisely documented. I think I will spend a few weeks to do that, because once this is finished, I'd like to be able to publish the entire design and its rationales on the web.
The statistics from the latest compilation run is as follows:
Code:
bash-2.05b$ gforth forth.fs
**** Kestrel Forth 1
Cross Compiler Release 1r1
Copyright (c) 2006 Samuel A. Falvo II
All Rights Reserved.
================================================================
Bytes Assembled: 2936
Data Stack Low: $87A
Data Stack High: $8FA
Entry Point: $1373
================================================================
Not too shabby, weighing in at only 3KB, and that's without tail-call optimization, and with inlining of certain primitives (averaging 12 bytes a pop)! My guess, based on these numbers, is that a Forth environment without blocks but with the colon compiler will fall in at just under 5K, and with block I/O support, will probably consume closer to 6K. If I were to include the assembler in the static image, it looks to be about 9K all-together. I can probably shrink it down somewhat by using pure STC instead of inlining certain primitives like pushing constants onto the stack. But I'll see about that only after it becomes a problem for me.
Login
Register
FAQ
Search
