> However, milliFORTH appears to be the smallest programming language implementation ever, beating out sectorLISP2, a mind-blowing 436 byte implementation of LISP, by 14 bytes.<p>The sectorlambda implementation of Binary Lambda Calculus is shorter yet at 383 bytes [1].<p>And the BLC self-interpreter is only 29 bytes [2].<p>> A FORTH in 422 bytes — the smallest real programming language ever, as of yet.<p>That may still be true, as BLC is an esoteric programming language.<p>[1] <a href="https://justine.lol/lambda/" rel="nofollow noreferrer">https://justine.lol/lambda/</a><p>[2] <a href="https://ioccc.org/2012/tromp/hint.html" rel="nofollow noreferrer">https://ioccc.org/2012/tromp/hint.html</a>
When I was in high school I wrote a nice FORTH for the TRS-80 Color Computer using the OS-9 operating system which was a Unix-like multitasking OS that would fit on a 6809 microcomputer.<p>I think it was around 2000 lines of assembly code to implement most of the FORTH-83 standard although mine was unusual in that it did not support the block-based I/O that was common on “language system” FORTHs but instead it had handle-based API for accessing files similar to Unix, C and MS-DOS in version 2 and up.<p>The programming environment was a lot like Linux overall in that I’d use an ed or vi clone to edit files, then run something like an assembler or C compiler. I’d run my FORTH binary and it would present an interactive environment like most FORTHs.
You could save one byte by replacing "0=" with "0<>" (well, except for the name, maybe use "0#"?):<p><pre><code> pop ax
neg ax ;sets carry flag if nonzero
sbb ax,ax
push ax
</code></pre>
And another two bytes in DOCOL:<p><pre><code> ;add ax,4
;mov si,ax
xchg ax,si
lodsw
lodsw
</code></pre>
Maybe even free up a word register to always hold the address of DOCOL, then you only need two bytes at each colon definition. If it's possible without adding any extra instructions, this should save 4 bytes in total (one stosw in COLON, the DOCOL.addr variable, one lodsw in the above version of DOCOL)
Looking at the code, this looks remarkably similar to sectorforth?
Thing is, with sectorforth and this, 2 of the primitives are not required so reducing the VM to 6ops, so you can probably go smaller. Looks as though Cesar was happy with fitting into a sector:
<a href="https://github.com/cesarblum/sectorforth/issues">https://github.com/cesarblum/sectorforth/issues</a>
When SectorLISP claimed to be the tiniest programming language in the world, it included (1) a Turing machine program, (2) an implementation of SectorLISP written in SectorLISP, and (3) a proof that it could run software that had been written for the original LISP 1.5 system built by LISP's inventor. If milliForth is making the same claim, then it should hold itself to the same standard. Otherwise it's just a calculator written by an anonymous person. I filed an issue here: <a href="https://github.com/fuzzballcat/milliForth/issues/8">https://github.com/fuzzballcat/milliForth/issues/8</a>
Does the benefit of it being embeddable on a QR code outweigh the lack of quality of life features like subtraction? Nevertheless, truly an impressive feat that shows how simple computers can be without all these modern API layers.
Look at how much room you have for data! I wonder what we can fit in there.<p>More seriously, a metacircular example to draw from would be: <a href="https://github.com/kragen/stoneknifeforth">https://github.com/kragen/stoneknifeforth</a>
Would it be possible to do a similar thing in a similar size for, for example, the 6502? I would love to give that a try, even though I probably lack the skills to make it that small. Or maybe it's even impossible.
Has anyone figured out how to pipe input to the qemu vm under WSL 2? I've tried all sorts of things, and nothing seems to work.<p>The included py_autotype.py takes forever, but nothing outputs in the qemu vm as it is running.<p>WSL 2 does have an X server running (xeyes works).<p>Update: running the script against gedit doesn't work either... it's not a qemu issue