3 ms·

I have done something along the lines of TFA a long time ago, a system that could boot from a floppy and recompile itself from source (never did anything useful

I have done something along the lines of TFA a long time ago, a system that could boot from a floppy and recompile itself from source (never did anything useful with it), but today I daily use a Forth dialect written in C that is designed to play nice with C and the OS. C is a sure bet. Interpreters that rely too much on JIT are simply not available on processors where the JIT is not available (duh), which was often the case for ARM before it became really popular. Same thing with relying on an emulator (also, you are running a VM in another kind of VM; it's usually bad for performance). As far as speed is concerned, if your Forth implementation makes it really easy to extend, you can always get something fast enough by re-coding the critical parts in C. That's why I stopped worrying about which implementation technique is the fastest and chose the one that made it the most trivial to extend the interpreter.

guerrilla 6y ago
Is that dialect written in C available online? I'm collecting implementations at the moment. If you know any other C implementations besides the popular ones I'd be grateful for pointers to those too.
- kragen 6y ago
  pfe ("portable Forth environment") was the first one I used; it was included in Slackware96 and included a Tetris game. You're probably aware GForth, BigForth, and F-83 are mostly written in Forth. I recently read through Retro-Forth, which compiles to an interpreter for a bytecode called Nga, written in C. There was another one I ran into recently but can't find now... aha, SOD32: https://lennartb.home.xs4all.nl/forth.html https://lennartb.home.xs4all.nl/forth.html
  - guerrilla 6y ago
    Thanks, SOD32 looks interesting. It also led me to find this: https://github.com/kt97679/relf https://github.com/kt97679/relf
- astrobe_ 6y ago
  I've been wanting to put it online for a long time to show how I do it for cases like this, but I need to strip it first of semi-confidential stuff because I hack it a lot to do work-related things. And it also need some documentation to be useful as an "educational" Forth. Maybe one day... For Forth implementations, although I suspect it might be yourself (you gotta admit this sort of fetish is not very common ;-), Charles Childers [1] is collecting them. [1] https://github.com/crcx?tab=repositories https://github.com/crcx?tab=repositories
kragen 6y ago
Cool! Do you still have a copy of it? Nowadays it's sometimes adequately fast to implement a JIT by spawning gcc or tcc and then running dlopen() on the result ;) It also makes the FFI easier :)
- astrobe_ 6y ago
  Technically I should still have a floppy and its backup, but the old laptop I used to make it is dead. It's kind of difficult to find floppy drives these days, and the whole thing is so old that the floppies might be no more readable. The dlopen trick is something I'll remember if I need that sort of stuff, but I've grown wary of FFIs. With libraries, there's often #define constants or macros that make FFIs a bit awkward. I prefer to use static linking if the lib is not too big, or dynamic loading but still with light bindings if not. If you know a bit the internals of Lua, I use a very similar method to extend Forth's "vocabulary", and the loading (and manual linkink with dlsym) is done only when the extension is invoked and initializes itself.
carapace 6y ago
> That's why I stopped worrying about which implementation technique is the fastest and chose the one that made it the most trivial to extend the interpreter. I like that, it appeals to my sense of pragmatism. I wrote a Joy interpreter in Nim the other day, and when it came time to switch from machine ints to BigInts it was a breeze. There was a library already written, I updated the type and the compiler told me what else to change, the whole thing was over in fifteen minutes. And if I ever find that integer math is a performance bottleneck there is also a wrapper for GMP ready to go. - - - - BTW, I'm a big fan of Oberon, and I think Astrobe is awesome and admire you for making and supporting it. Cheers!

guerrilla 6y ago

Is that dialect written in C available online? I'm collecting implementations at the moment. If you know any other C implementations besides the popular ones I'd be grateful for pointers to those too.

kragen 6y ago
pfe ("portable Forth environment") was the first one I used; it was included in Slackware96 and included a Tetris game. You're probably aware GForth, BigForth, and F-83 are mostly written in Forth. I recently read through Retro-Forth, which compiles to an interpreter for a bytecode called Nga, written in C. There was another one I ran into recently but can't find now... aha, SOD32: https://lennartb.home.xs4all.nl/forth.html https://lennartb.home.xs4all.nl/forth.html
- guerrilla 6y ago
  Thanks, SOD32 looks interesting. It also led me to find this: https://github.com/kt97679/relf https://github.com/kt97679/relf
astrobe_ 6y ago
I've been wanting to put it online for a long time to show how I do it for cases like this, but I need to strip it first of semi-confidential stuff because I hack it a lot to do work-related things. And it also need some documentation to be useful as an "educational" Forth. Maybe one day... For Forth implementations, although I suspect it might be yourself (you gotta admit this sort of fetish is not very common ;-), Charles Childers [1] is collecting them. [1] https://github.com/crcx?tab=repositories https://github.com/crcx?tab=repositories

kragen 6y ago

Cool! Do you still have a copy of it? Nowadays it's sometimes adequately fast to implement a JIT by spawning gcc or tcc and then running dlopen() on the result ;) It also makes the FFI easier :)

astrobe_ 6y ago
Technically I should still have a floppy and its backup, but the old laptop I used to make it is dead. It's kind of difficult to find floppy drives these days, and the whole thing is so old that the floppies might be no more readable. The dlopen trick is something I'll remember if I need that sort of stuff, but I've grown wary of FFIs. With libraries, there's often #define constants or macros that make FFIs a bit awkward. I prefer to use static linking if the lib is not too big, or dynamic loading but still with light bindings if not. If you know a bit the internals of Lua, I use a very similar method to extend Forth's "vocabulary", and the loading (and manual linkink with dlsym) is done only when the extension is invoked and initializes itself.

carapace 6y ago

> That's why I stopped worrying about which implementation technique is the fastest and chose the one that made it the most trivial to extend the interpreter. I like that, it appeals to my sense of pragmatism. I wrote a Joy interpreter in Nim the other day, and when it came time to switch from machine ints to BigInts it was a breeze. There was a library already written, I updated the type and the compiler told me what else to change, the whole thing was over in fifteen minutes. And if I ever find that integer math is a performance bottleneck there is also a wrapper for GMP ready to go. - - - - BTW, I'm a big fan of Oberon, and I think Astrobe is awesome and admire you for making and supporting it. Cheers!