3 ms·

I love that it produces actual runnable binaries instead of emitting assembly or C, like so many tiny compilers do. I know it's technically the job of the assem

I love that it produces actual runnable binaries instead of emitting assembly or C, like so many tiny compilers do. I know it's technically the job of the assembler and the linker, but without these parts it kinda feels like cheating.

carapace 6y ago
For this sort of thing I bounce back and forth between targeting C vs ASM. C is so universal and there are so many tools you can use to harden it. On the other hand, you're still using a big ol' abstraction layer between C and the machine. On the gripping hand, CPUs are doing so many things under the hood now that ASM can be considered an abstraction layer obscuring the actual machine, so you kind of need a modern compiler to have a hope of taking advantage of all that without doing a ton of research. Over on the "αcτµαlly pδrταblε εxεcµταblε" page ( https://justine.lol/ape.html https://justine.lol/ape.html ) there's a subsection called "x86-64 Linux ABI Makes a Pretty Good Lingua Franca" it seems to me to be a reasonable suggestion (although I've never like x86 myself.) You can bundle an x86 emulator with your code to run on other architectures. I like the Project Oberon 32-bit RISC developed by Prof. Wirth as a target. It's really simple for educational purposes. (Meaning you can more easily teach more people Oberon RISC than, say, RISC-V. ALthough see the "Selfie" project: https://selfie.cs.uni-salzburg.at/ https://selfie.cs.uni-salzburg.at/ "An educational software system of a tiny self-compiling C compiler, a tiny self-executing RISC-V emulator, and a tiny self-hosting RISC-V hypervisor.") There are many emulators for Oberon RISC already, including one in Javascript, so you can run the old Oberon OS in your browser! Launch an emulator with a disk image from here: https://schierlm.github.io/OberonEmulator/ https://schierlm.github.io/OberonEmulator/
- astrobe_ 6y ago
  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 :)

carapace 6y ago

For this sort of thing I bounce back and forth between targeting C vs ASM. C is so universal and there are so many tools you can use to harden it. On the other hand, you're still using a big ol' abstraction layer between C and the machine. On the gripping hand, CPUs are doing so many things under the hood now that ASM can be considered an abstraction layer obscuring the actual machine, so you kind of need a modern compiler to have a hope of taking advantage of all that without doing a ton of research. Over on the "αcτµαlly pδrταblε εxεcµταblε" page ( https://justine.lol/ape.html https://justine.lol/ape.html ) there's a subsection called "x86-64 Linux ABI Makes a Pretty Good Lingua Franca" it seems to me to be a reasonable suggestion (although I've never like x86 myself.) You can bundle an x86 emulator with your code to run on other architectures. I like the Project Oberon 32-bit RISC developed by Prof. Wirth as a target. It's really simple for educational purposes. (Meaning you can more easily teach more people Oberon RISC than, say, RISC-V. ALthough see the "Selfie" project: https://selfie.cs.uni-salzburg.at/ https://selfie.cs.uni-salzburg.at/ "An educational software system of a tiny self-compiling C compiler, a tiny self-executing RISC-V emulator, and a tiny self-hosting RISC-V hypervisor.") There are many emulators for Oberon RISC already, including one in Javascript, so you can run the old Oberon OS in your browser! Launch an emulator with a disk image from here: https://schierlm.github.io/OberonEmulator/ https://schierlm.github.io/OberonEmulator/

astrobe_ 6y ago
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 :)