stoneknifeforth VS bootOS

Compare stoneknifeforth vs bootOS and see what are their differences.

stoneknifeforth

a tiny self-hosted Forth implementation (by kragen)

bootOS

bootOS is a monolithic operating system in 512 bytes of x86 machine code. (by nanochess)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
stoneknifeforth bootOS
13 9
405 1,771
- -
0.0 4.1
almost 4 years ago 4 months ago
Forth Assembly
Creative Commons Zero v1.0 Universal BSD 2-clause "Simplified" License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

stoneknifeforth

Posts with mentions or reviews of stoneknifeforth. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-03-02.
  • Konilo: A personal computing system in Forth
    5 projects | news.ycombinator.com | 2 Mar 2024
  • Writing a Compiler is Surprisingly Easy (part 1)
    5 projects | news.ycombinator.com | 7 Nov 2023
    a problem that a lot of these series run into is that the author runs out of steam before they finish writing them. crenshaw's otherwise excellent series suffers from this, for example

    so far the author of this one has only written the first chapter

    i've written a few didactic compilers that are complete enough to compile themselves, though nothing else

    https://github.com/kragen/stoneknifeforth (from a forth-like language to an i386 linux elf executable)

    https://github.com/kragen/peg-bootstrap/blob/master/peg.md (from a peg language description with semantic actions to javascript)

    http://canonical.org/~kragen/sw/urscheme (from a subset of scheme to at&t-syntax i386 assembly)

  • MilliForth
    4 projects | news.ycombinator.com | 5 Nov 2023
    Look at how much room you have for data! I wonder what we can fit in there.

    More seriously, a metacircular example to draw from would be: https://github.com/kragen/stoneknifeforth

  • Lisp as the Maxwell’s Equations of Software
    1 project | news.ycombinator.com | 9 Nov 2022
    i wasn't able to get a runnable forth to less than a couple of pages written in itself https://github.com/kragen/stoneknifeforth but schönfinkel's ski-combinators are maybe the simplest practical basis

        s f g x → f x (g x)
  • Stop Writing Dead Programs (Transcript)
    7 projects | news.ycombinator.com | 18 Oct 2022
    I've done all these things (except designing the hardware) and I agree that it can be very painful. I did some of them in 02008, for example: https://github.com/kragen/stoneknifeforth

    The thing is, though, you can also not do all those things. You can use variables, and they don't even have to be allocated on a stack (unless you're writing a recursive function, which you usually aren't), and all the NIP TUCK ROT goes away, and with it all the Memory Championship tricks. You can test each definition interactively as you write it, and then the fact that the language is absurdly error-prone hardly matters. You can use metaprogramming so that your code is as DRY as a nun's pochola. You can use the interactivity of Forth to quickly validate your hypotheses about not just your code but also the hardware in a way you can't do with C. You can do it with GDB, but Forth is a lot faster than GDBscript, but that's not saying much because even Bash is a lot faster than GDBscript.

    But Yossi was just using Forth as a programming language, like a C without local variables or type checking, not an embedded operating system. And, as I said, that's really not Forth's strength. Bash and Tcl aren't good programming languages, either. If you try to use Tcl as a substitute for C you will also be very sad. But the way they're used, that isn't that important.

    I explained a more limited version of this 12 years ago: https://yosefk.com/blog/my-history-with-forth-stack-machines...

    So, I don't think Forth is only useful when you have the freedom to change the problem, though programs in any language do become an awful lot easier when you have that freedom.

  • StoneKnifeForth
    5 projects | news.ycombinator.com | 17 Jul 2022
  • A complete compiler and VM in 150 lines of code
    4 projects | news.ycombinator.com | 16 Jul 2022
    That's powerful enough to conveniently write, for example, a numerical root finding program for an arbitrary arithmetic expression.

    But I think that within a complexity budget of 150 lines of code you can maybe be even more ambitious than that.

    The example compiler in https://github.com/darius/parson/blob/master/eg_calc_compile... is a bit more stripped down than that, but in its 32 lines of code it compiles arithmetic assignment statements to a three-address RISC-like code (though using an unbounded number of registers). https://github.com/darius/parson/blob/master/eg_calc_to_rpn.... is a 16-line version that compiles the same language to a stack machine like your tutorial example.

    In 66 lines of code in https://github.com/kragen/peg-bootstrap/blob/master/peg.md I wrote an example compiler which compiles a PEG grammar into a JavaScript parser for that grammar. Admittedly those 66 lines do not include an implementation of JavaScript to run the code on. It compiles the language it's written in.

    In 132 lines of code in https://github.com/kragen/stoneknifeforth/blob/master/tinybo... I wrote an example compiler which compiles a crippled Forth dialect into i386 machine code, including an ELF header so you can run the result. It also compiles the language it's written in. It also doesn't include an i386 emulator to run it on.

    In 83 lines of code in http://canonical.org/~kragen/sw/dev3/neelcompiler.ml Neel Krishnaswami wrote a compiler from the untyped λ-calculus to a simple assembly language for a register machine. It also doesn't include an implementation of the assembly language.

    In 18 lines of code in http://canonical.org/~kragen/sw/dev3/meta5ix.m5, a simplification of META-II, I wrote a compiler from grammar descriptions to an assembly code for a parsing-oriented virtual machine. It compiles the language it's written in. A Python interpreter for the machine is in http://canonical.org/~kragen/sw/dev3/meta5ixrun.py (109 lines of code) and a precompiled version of the compiler-compiler for bootstrapping is in http://canonical.org/~kragen/sw/dev3/meta5ix.generated.m5asm.

    A slightly incompatible variant of Meta5ix which instead compiles itself to C is in http://canonical.org/~kragen/sw/dev3/meta5ix2c.m5 (133 lines of code, depending on how you count). (No C compiler is included.) The precompiled C output for bootstrapping is in http://canonical.org/~kragen/sw/dev3/meta5ix2c.c.

    Meta5ix is extremely weak and limited, really only enough for a compiler front-end; it can't, for example, do the kinds of RPN tricks we're talking about above.

  • Looking for a simple forth compiler (producing asm/executables, not compiling forth words) to learn from, preferably in C family language
    5 projects | /r/Forth | 7 Aug 2021
    Title effectively says it all. The only thing I have found is StoneKnife Forth (implementation is in tinyboot1.tbf1) but this file is implemented in the same dialect of forth it implements, which due to being minimal makes it difficult to read and comprehend efficiently (I also can't find the origin of some words such as 'byte' used in the code but not implemented by the interpreter). I would prefer something in the C family to look at but anything should do as long as it's clean enough that I could use it as a reference to reimplement the compiler without much difficulty. Thank you in advance for any help with what is seemingly quite a narrow request.
  • An HTTP server in a single .c file
    12 projects | news.ycombinator.com | 2 Apr 2021
    I'm pretty sure Linux ELF has always allowed you to specify the initial load address. When I first wrote StoneKnifeForth https://github.com/kragen/stoneknifeforth its load address was 0x1000, but at some point Linux stopped allowing load addresses lower than 0x10000 by default (vm.mmap_min_addr). I originally wrote it in 02008, using the lower load address, and fixed it in 02017. It's still not using 0x804800 like normal executables but 0x20000. ASLR does not affect this.

    Maybe you mean that before ELF support, Linux a.out executables had to be loaded at a fixed virtual address? That's possible—I started using Linux daily in 01995, at which point a.out was already only supported for backward compatibility.

  • StoneKnifeForth (With a Metacircular Compiler)
    6 projects | news.ycombinator.com | 18 Feb 2021

bootOS

Posts with mentions or reviews of bootOS. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-05-24.
  • A monolithic operating system in 512 bytes of x86 machine code
    1 project | /r/patient_hackernews | 7 Jun 2023
    1 project | /r/hackernews | 7 Jun 2023
    1 project | /r/hypeurls | 7 Jun 2023
    1 project | news.ycombinator.com | 7 Jun 2023
  • SectorC: A C Compiler in 512 bytes
    7 projects | news.ycombinator.com | 24 May 2023
    wow, this is impressive.

    I wrote a similar x86-16 assembler in < 512 B of x86-16 assembly, and this seems much more difficult <https://github.com/kvakil/0asm/>. I did find a lot of similar tricks were helpful: using gadgets and hashes. Once trick I don't see in sectorc which shaved quite a bit off of 0asm was self-modifying code, which 0asm uses to "change" to the second-pass of the assembler. (I wrote some other techniques here: <https://kvakil.me/posts/asmkoan.html>.)

    bootOS (<https://github.com/nanochess/bootOS>) and other tools by the author are also amazing works of assembly golf.

  • StoneKnifeForth
    5 projects | news.ycombinator.com | 17 Jul 2022
    I'm glad you enjoyed it! Have you tried running it?

    One could reasonably argue that SKF isn't really "booting" on an old 386 PC; though it'll probably run on one, you need to get Linux running on the PC first, because SKF can't read the input source code from disk or write the output executable to disk on its own, and it needs something to load it into memory and start it running as well. And, unlike real Forths, it's a batch-mode compiler: it can't be used interactively. The sense in which it's a "tiny bootstrap" is that it's a compiler that compiles itself, not the sense of "bootstrapping" that means to load oneself into RAM.

    — ⁂ —

    In 02007 I wrote https://github.com/kragen/tokthr as an investigation into precisely the question of "just how small a fully functional Forth environment could be packed". By using bytecode ("token threading") rather than DTC or ITC, tokthr provides "90% of" a traditional interactive Forth environment in about 1400 bytes, all bytecode except for a 239-byte machine-code core. Unfortunately, because it's incomplete, it's impossible to know whether the remaining 10% of the functionality requires adding another 10% to the code or another 90%—as in the old joke about how the first 90% of the project takes the first 90% of the schedule, and the remaining 10% takes the other 90%.

    My best guess, though, is that it'd be about 1700 bytes, so in 2KiB you'd have about 350 bytes left for the user program, which is probably about 64–128 lines of code. Interpretation can be slow, but it sure makes for denser code, and you don't need to have two copies of the interpreted code in RAM when you're bootstrapping.

    There have definitely been 8KiB interactive Forth systems, and I think there have been 4KiB ones, which was also the size Wozniak required for a BASIC interpreter on the Apple. tokthr suggests that 2KiB might be achievable for a stripped-down Forth.

    Óscar Toledo G.'s bootOS https://github.com/nanochess/bootOS is a particularly interesting non-Forth system in this OS/IDE/debugger vein, because it has enough functionality to write programs (in hexadecimal machine code), load them from disk, edit them, and save them, all in 512 bytes of code. It does require somewhat more than 512 bytes of RAM, but still very little—much less than has ever been present on a machine that it could run on.

    — ⁂ —

    My thinking on Forth, which is something I'm an amateur at, has changed a little bit since I wrote tokthr and SKF. I think that if you evaluate Forth as a programming language, it's generally going to look pretty deficient. It's more bug-prone and harder to read than alternatives like C, Lisp, BASIC, or assembly language, although it does support compile-time metaprogramming and powerful abstraction facilities.

    But if you ask the question, "What's the simplest usable development environment I can build?" the answer starts to look a lot like Forth, especially if you're running on a poorly characterized piece of hardware where you need to prioritize interactive experimentation with I/O ports. It gives you an interactive, scriptable environment for poking around, similar to what Tcl gives you https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html but in 4 kilobytes rather than the megabyte and a half Tcl demands. And the environment includes not just a scriptable command line and the usual programming-language things like arithmetic, subroutines, variables, and arrays, but also compile-time metaprogramming, virtual memory, an editor that allows you to recompile code at screenful granularity (usually), a memory dumper, access to raw hardware devices, an assembler (usually), sometimes multithreading, and a sort of debugger.

    As in BASIC or Lisp or Python or Tcl, your UI is a REPL, so your programming language is also your command language; but, unlike in BASIC, your command language is extensible, so in many cases it can also work as the user interface to your application.

    In BASIC or in a C debugger you number the lines of code in your program; in Forth you name them, so you can "single-step" your program by running them one at a time. Then the ? word gives you a quick way to examine your variable values interactively, again as in a debugger. Like, here's me trying to interactively debug a square-root routine into existence in GForth on Linux:

        variable square variable guess  ok
  • BootOS operating system in 512 bytes
    3 projects | news.ycombinator.com | 27 Aug 2021
  • BootOS: A monolithic operating system in 512 bytes of x86 machine code
    1 project | news.ycombinator.com | 31 Jul 2021
  • The Kilobyte's Gambit: Can you beat 1024 bytes of JavaScript [at chess]?
    2 projects | news.ycombinator.com | 7 Mar 2021
    He also wrote bootOS, "a monolithic operating system in 512 bytes of x86 machine code."

    https://github.com/nanochess/bootOS

What are some alternatives?

When comparing stoneknifeforth and bootOS you can also consider the following projects:

jonesforth - Mirror of JONESFORTH

sectorforth - sectorforth is a 16-bit x86 Forth that fits in a 512-byte boot sector.

durexforth - Modern C64 Forth

sunfish - Sunfish: a Python Chess Engine in 111 lines of code

factor - Factor programming language

bcc - bcc is a b compiler

r4 - :r4 concatenative programming language with ideas from ColorForth.

bootstrap-seeds - The roots of trust for all architectures

r3d4 - r3 programing language for 64 bits Windows/Linux/Mac/Rasberry Pi 4

sectorc - A C Compiler that fits in the 512 byte boot sector of an x86 machine

http - A simple multi-threaded HTTP/1.0-ish file server. Single file, ~250 LOC.

live-bootstrap - Use of a Linux initramfs to fully automate the bootstrapping process