This is an interesting idea but I'm not sure fitting in L1 caches would work that well for threaded Forths. Most CPUs align on word boundaries based on their pipeline size and unless you organize your Forth around both the L1 size and the instruction pipeline, you're gonna get huge pipeline stalls and pay branch predictor penalties. Also with modern processors you're gonna pay a huge hit with stack operations as opposed to using registers.
As far as using OO Forth, you can also just use specific words that offer a safe interface over more dangerous raw memory words. Old Forths probably worked directly with the filesystem more because of code size limitations than any real abstraction penalty.
The forth base I was thinking of is Freeforth, which is an STC Forth that assigns registers to the top two stack elements to avoid SWAP instructions.
I take your point about caches, but surely a Forth like this that optimises the words during compile (inlining etc) would help?
I guess that this hypothetical stc Forth would have to have abstracted I/O and registers- any spare ones outside the stack management could be used for data passing, maybe as the top of the data stack.
Of note, this cache friendliness would dictate the kernel wordset, so choosing it would be dependent on your cpu targets.
Really the OO is in support of vocabulary modules and data spaces. Freeforth has a cross compiler environment to MSP430 cpus - as a module this would make hygienically writing to new targets easy.
I took a look at Freeforth. It's a pretty innovative Forth.
> which is an STC Forth that assigns registers to the top two stack elements to avoid SWAP instructions. I take your point about caches, but surely a Forth like this that optimises the words during compile (inlining etc) would help?
Certainly. The way Freeforth seems to be doing things is by storing the swapped state and by testing against that to make a branch. I'm curious how this works with branch predictor penalties, but if swaps are done in loops then it might actually work out very favorably. You need to be careful that your code doesn't use too much ROT or DUP but as long as it's mostly SWAP oriented it should be okay.
> I guess that this hypothetical stc Forth would have to have abstracted I/O and registers- any spare ones outside the stack management could be used for data passing, maybe as the top of the data stack.
Forth implementations are notoriously architecture specific for exactly this reason and the differences in registers and stack semantics between architectures. A lot of recreational Forths target abstract VMs exactly to be able to target a single architecture and not care much about performance, but if you want to adapt Freeforth to different architectures you may need to make deep changes. I'm not sure how FASM works but maybe FASM decreases some of the pain.
As far as using OO Forth, you can also just use specific words that offer a safe interface over more dangerous raw memory words. Old Forths probably worked directly with the filesystem more because of code size limitations than any real abstraction penalty.