Brilliant! I love the name TENTH, which is 40% of FORTH.
If you're not playing with 36 bits, you're not playing with a full DEC.
I wonder if there's a way to use the PDP-10's repeated indirect bit effective address calculation to efficiently thread Forth code, or implement higher level words like <BUILDS and DOES> by bunny-hopping through the CFA (Code Field Address)? [1]
I had the same thought at first but somehow all the indirections were confusing me and I think it makes things more difficult than necessary. What I plan to do however is to use direct threading instead since a JRST takes no more space than the mere address of course. That would make NEXT a bit simpler and save some space.
Have you checked out the NOVIX Forth Chip? That has a lot of great ideas you could apply, or at least find entertaining!
It had a horizontal bitslice architecture, and separate independent busses for main memory, operand stack and return stack, so several forth words that did some stack manipulation, used the alu, and returned from a call, could all be collapsed into one instruction that accessed main memory, the operand stack, and the return stack at the same time!
No, I'm not a forth expert btw. I find forth interesting and wanted to write something to run on the PDP-10 but I've yet to write some non-trivial forth code.
Your direct threading approach sounds like a good technique for the PDP-10.
The NOVIX chip is way different that what you're doing, since it has its own instruction set and a pretty fancy compiler. The set of FORTH words it chooses as its instruction set is a good example of a minimal FORTH kernel.
Don, what do you think about the eForth Model and the F18 instruction sets? I've been thinking a lot lately about minimal practical instruction sets. I'll check out the NOVIX, which I had of course heard of but never dug into — thanks for the recommendation!
It would be cool to add some FORTH words to support arbitrarily sized byte addressing!
Mitch Bradley's Forth (which evolved into Open Firmware) [1], which is a purposefully word-size agnostic dialect, had the decoratively named word @c@++ which pops an address and pushes the address incremented by one ("++") and the byte at ("c@") the initial address ("@"), and the corresponding word @c!++ which went the other way. On a PDP-10 Forth that address could be a sized byte pointer!
If you had a complete set of arbitrarily sized byte processing words, then you could implement your string words in FORTH on top of those, and use whatever byte size for strings you want!
Yeah, I was thinking about something similar to this. The other idea I had was to have virtual byte addresses (some flags in the left halfword would be set) that are converted to real byte addresses on use. This means you could perform pointer arithmetic on them without needing extra words for that. On the other hand you'd have to convert them all the time...
This is seriously impressive work. And writing an assembler to build a compiler is also in the long tradition of craftsmen/craftswomen making their own tools for use in creating their ultimate objective.
My plan is to have my B compiler (https://github.com/aap/abc) spit out PDP-10 assembly eventually. It would be a perfect fit since B assumes word addressed memory.
I showed this to my boss who likes to talk about DEC, and how the PDP-10 was his "first computer in college". First he smiled then "said ohhhh what a useless exercise" then launched into a half hour of stories about programming the thing.
If you're not playing with 36 bits, you're not playing with a full DEC.
I wonder if there's a way to use the PDP-10's repeated indirect bit effective address calculation to efficiently thread Forth code, or implement higher level words like <BUILDS and DOES> by bunny-hopping through the CFA (Code Field Address)? [1]
https://en.wikipedia.org/wiki/PDP-10#Instructions