This new section of the forum is for discussing Forth implementations on the 65-family processors. I asked Mike Naberezny to open it up because several of us have been discussing this material privately in E-mail over the last few years, without the benefit of possible contributions from others, and without leaving any archives for others to benefit from either.

On my workbench computer, I'm using an indirect-threaded 65c02 Forth kernel that had its roots back in the public-domain fig-Forth model written by Ragsdale, was picked up by a metacompiler supplier that made small changes to it, and ultimately given a ton of additions and modifications through my own use over the last 14 years. One of my early additions was zero-overhead interrupt service in high-level Forth. It's very simple and does not require setting up another pair of stacks or any of the stuff people usually think is necessary. Mike should have the article on that posted soon.

I've written an extensive indirect-threaded 65816 Forth assembly source which Wally Daniels is "beta testing." He went for a long time without finding any bugs, but finally found one a couple of weeks ago and just yesterday discovered a problem in DOES> that I'll have to find a way to correct.

Samuel Falvo (I hope you guys don't mind me using your names-- they'd be on the forum anyway if we had been discussing these things on it) has been interested in writing a subroutine-threaded '816 Forth and has some great ideas for dictionary hashing and very fast compilation.

It sounds like Bruce Clark has some performance improvements to my UM/MOD article that are waiting to be posted. Since I'm not in a competition, this doesn't bother me at all. If it does the job just as well and can improve the performance of my Forths, terriffic. That's what the website is for.

Additionally, Bruce Clark, Douglas Beattie, Phillip Eaton, and others on the 6502.org forum whose names escape me at the moment have a good head on their shoulders and I look forward to some beneficial discussion.

The 6502 is very becoming of Forth. One write-up I read on implementations of high-level languages said Forth would be entirely impractical on the 6502 because of the 6502's small stack space. The writer must not be experienced in the field. The 6502's hardware stack in page 1 which we use for the return stack, as well as the ZP space for the data stack, are several times as much as you need to run just Forth. (Maybe he was thinking of putting a large array on the stack instead of just the address?) X makes the perfect data stack pointer too, even though it's only 8 bits. Indirect-threaded Forth is extremely memory-thrifty compared to other languages, allowing surprisingly large applications to be run within the 6502's memory space.

Possible topics of discussion that come to mind include:

threading types
multi-tasking
implementation of extra stacks (floating-point, ANS's control flow stack, etc.)
algorithms
ROM-based versus RAM-based kernels
what to do when the host OS hogs most of ZP
Forth philosophies and how they relate to the 65 family
use of macros in assembly source code for Forth kernels
projects and uses of Forth on 65-family processors
24- or 32-bit models on the '816
etc. etc.

Discuss!

Cool forum. So . . . where are the donuts?

I should point out that I am brutally masochistic when it comes to Forth implementations. My feeble mind cannot handle much implementation complexity. Hence, all my recent Forth implementations have been MachineForth implementations. Some might therefore call me a devout follower of Chuck Moore. In a sense, they would be right.

Working on my Kestrel project, I now have a MachineForth cross assembler/compiler for my FTS1001 CPU design that is about 50 lines of source long (the file actually has close to 200 lines, but much of it is comments). Porting this same MachineForth compiler to x86 would not be difficult -- the basic structure of it is intended to replace my existing FTS/Forth Cross Compiler, which is already capable of generating statically linked, self-standing Linux executables. Porting it to the 65816 wouldn't be hard either, but I would have to verify the primitives against the 65816 CPU's instruction set to tailor it for best run-time performance. For example, the 65816 makes post-incrementing a memory pointer hard, because you either increment an index register, or you increment a memory pointer. Incrementing an index register is fast, but it requires a pointer to consist of two separate fields (a base pointer and an offset), while the latter is just plain slow. Thus, while primitives like !A and @B can exist, !A+ and @B+ most likely would need to be removed and replaced with alternatives. In their place, I'd include primitives which took advantage of indexing.

It's important to remember that any port of the MachineForth compiler would be its own separate product; by definition, we're working with machine-level resources, and 100% source level compatibility cannot be guaranteed across platforms. I do not believe in one language fits all. Besides, Forth is malleable enough that it's possible to write a compatibility layer for applications written on another Forth environment in small handful of hours, and things just start working. I love it.

There is, of course, a place for more "standard" Forth implementations too. I'm not trying to dissuade their use (I note that my cross assemblers are currently written using GForth, an implementation of ANSI Standard Forth). And for the purposes of LEARNING Forth, I WHOLLY advocate their use. One should not "strike out on their own" like I am until they understand the basic concepts and philosophies behind Forth first.

Anyway, the point of this whole post is two-fold: first, I'm a weirdo when it comes to Forth. I'm out there. Not on the bleeding edge (obviously, as Chuck Moore has already experimented with these concepts), but very clearly not on solid, well-worn turf like most everyone else either. And second, because I'm more daring when it comes to Forth, I have a unique perspective on things which actually can help one understand traditional Forth systems better. Do you have a complex problem that you can't find an easy way to solve? It's possible that I can solve the problem. Maybe the solution isn't as obvious, or as likable, as you might like. But often times, it just takes a different way of looking at things -- a different philosophy.

But I'll get off my soap-box for now.

Great idea to add a Forth topic. I've been playing around with the language sinc I got a copy of the August 1980 BYTE magazine on the subject, and Loeliger's book.

I've been working on a new 6502 Forth implementation that meets the ANS standard based on bits of FigForth and a 6809 Camel Forth. As I don't have a real SBC I've been targeting Daryls SBC emulator.

I hate writing multiply and divide primitives so I'll be borrowing Garth's UM/MOD from the library.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.demon.co.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.demon.co.uk/dev65/

I don't just hate writing primitives. If at all possible, I avoid the hard work.

In a Forth system I'm writing, about 10% of the code is borrowed from others. (For instance, is , guess which one this comes from (hint: it starts with an e and a Forth))

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"

2OVER in '816 Forth is just:

Much faster, and, I think, easier too. There were so many things that were easier to write as primitives when I did my 65816 Forth. The '816 really is easier to program.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources