12 ms·
By that metric, my implementation of romforth for x86 clocks in at just 12 bytes (see https://github.com/romforth/romforth/x86/forth.s https://github.com/romfor
by romforth 1y ago
By that metric, my implementation of romforth for x86 clocks in at
just 12 bytes (see https://github.com/romforth/romforth/x86/forth.s https://github.com/romforth/romforth/x86/forth.s)
The "bug" in the counting used here is that the overall Kolmogorov(?)
complexity is not being accounted for because it is shunted elsewhere.
This is true for the other "tinyforth" implementations as well - such as
sectorforth and milliforth, because the actual code ends up in the
"input part of the Turing tape" if you want to think of it that way.
The right way to count it might be to measure the closure of all your
dependencies (in this case, all of the input bytes that are needed plus
the bytes in the BIOS that are needed).
- anthk 1y agoThat's what I tought. Even Miliforth lacks a proper complete integer based stack. From that and a few primitives, you can bootstrap a Forth. On Lisp, Sectorlisp it's interesting; but the ones from https://t3x.org https://t3x.org can do far more, even if they are not bootable per se. But T3XForth can, and it's highly usable. EForth under SUBLEQ it's like that too. Instead of "Boot sector languages", I'd pursuit a 386 compatbile language being able to fit in a floppy. T3XForth does, and tons more, because the T3X author made eiher standalone ones, or DOS and CP/M 2.2 ports.