ohhh noooo I am definitely going to write a 16-bit x86 Forth as a scripting language for my game, this is happeniiiiing
Slowly dawning on me why people write editors in forth
Like, I have a repl, and it's great, but what I really need is a window next to my repl with all my code in it, and that's not a thing I get to have on a single-tasking system which will run over a serial port, sorry
A little decompiler would be pretty easy to write and would be a good 80% solution though
Now that I've got a working kernel, and I added the ability to load source from a file, it is so much fun to flesh out the language from inside itself!
I refactored if/else/then into forth words after reading the source to another forth and realizing how close I already was. Then I wrote a looping construct begin/while/repeat in forth 'cause it was really not any harder than writing if/else/then. Then I implemented comments. Should probably take on string literals next.
One of the really nice things about writing your own forth is that there is so much useful documentation still out there about how to implement various features. Brad Rodriguez's writing in particular is a treasure; today's gem is this wonderful overview of multitasking http://www.bradrodriguez.com/papers/mtasking.html
So I implemented cooperative multitasking yesterday, which means:
* I can run the serial port REPL in its own isolated task (necessary if I want to interactively define multilline words while the main game loop is running)
* I can write high-level coroutine-style scripts, like dialogue trees, very easily, which is the whole reason I wanted an interpreted language for my game in the first place
One thing that I'm definitely noticing is that defining everything as words and defining most context as implicit means you have a LOT of leverage in changing the implementation of things.
Before I implemented multitasking, "STATE" (meaning "should the interpreter loop act as a compiler or an interpreter") was a global C variable. I tweaked it to be stored in the task-specific "user data" area of memory, parameterized by the currently-running task, and no code that used it had to know.
@SpindleyQ Have you used forth before? It's like programming in assembly on a CPU designed by an alien. It'll be a long learning curve before it's a workflow improvement on writing x86 asm directly.
Like, obviously you're doing a lot of things the hard way on purpose right now. But know what you're getting into!
@mogwai_poet oh yeah, I got deeeeep into trying to figure out Forth in my early twenties. Part of what makes it so attractive right now, as part of this project, is that I didn't _quite_ have the chops to build my own back then. _Everything_ I'm doing for this game is like that.
I think there's a reasonable tiny subset I can build quickly that'll be worth the trouble; I'm not out to build an OS out of it or anything.
@cstrotm I haven't thought too much about distribution yet, but the reason my Forth exists is basically because I wanted to try writing a Forth, and it is likely to be extremely feature-poor, idiosyncratic, and poorly-architected. Literally threw this together in a few hours, still not sure how to write IF.
But it might show up in a public git repo someday, sure
@cstrotm I believe it's Turbo C++ 1.01 with TASM 2, but I honestly forget exact versions. 1990-era Borland, anyway. Not using C++.
It's an indirect threaded interpreter, using https://www.bradrodriguez.com/papers/moving1.htm as a reference, with pointers to standard C functions in the code field. I want to use an external return stack rather than the C stack so that I can have tail calls & easily suspend computations (specifically when fetching the next input character) but right now it's a weird buggy mix of both.
@SpindleyQ I'm planning to use the new 16bit backend of GCC
Turbo-C is good for old code or for writing new code for old machines, but for porting existing code or creating portable code GCC might be easier (my hope).
does an incredible job of being portable from old Turbo-C to current C-Compiler. But I'm not a C language expert enough to reach the same level of portability.
@cstrotm Is there any documentation for that backend? Curious to know what the memory models are & how / if they handle far pointers.
AFAIK Turbo C is ANSI-compliant - I've read that you can build fairly recent versions of Lua with it.
The original server operated by the Mastodon gGmbH non-profit