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