romforth

https://github.com/romforth/romforth already has a port to RISV-V for both 32 and 64 bit, (among many others). So if you don't mind lowering your language implementation to romforth (or even rewriting your compiler to directly generate it), you should be able to use it "for free", no funds required ;)

You jest, but I did end up doing just that in my implementation (https://github.com/romforth/romforth) trying to shoehorn a Forth implementation into a MSP430 device with just 2KB ROM + 128 byte RAM

So you had your heart set on running Forth on a microcontroller with 512 bytes of ROM and 64 bytes of RAM? Here you go!

This one boots from the parallel port: https://github.com/climatex/BootLPT (more details here https://boginjr.com/it/sw/dev/bootlpt-86/)

It will be interesting to see how much further this can be taken.

For anyone interested in attending the meeting today. Past meeting notes are at: https://www.forth.org/svfig/kk/kk.html

Hello HN,

Tree Walk Format (TWF) is a flat file format to describe your family tree. It allows you to describe your family tree in one (or more) files which are editable using your favorite text editor.

I see it as a viable alternative to GUIs such as Gramps or TUIs such as llines(Lifelines).

Currently it is Unix/Linux only since it uses groff/dot to generate the graph depicting the family tree. The git repo has a script that turns the flat file you created into a pdf depicting your family tree. I assume Windows users may be able to use it too using WSL.

It should be possible to generate an equivalent GEDCOM from the TWF input, but that is not implemented yet.

Some additional usage info including examples of family trees from the Bible which are denoted using the TWF format are available at: https://ces.mataroa.blog/blog/twf_ftwmd

Allow me to brag about romforth (https://github.com/romforth/romforth) which I ported to the "3c" Padauk and can run on really small rom/ram microcontrollers. Caveats: - tested only on an emulator SDCC/ucsim_pdk, not on real hardware - given how small the ram is, there is no user dictionary but new words can be defined and tested using what the Forth folks refer to as "umbilical hosting".

Feel free to check out https://github.com/olvwm/xview/ as well.

I wanted to run olvwm on Linux (when it went out of support on Ubuntu 16.04) and I'd managed to get this running on Ubuntu 20.04 (and more recently on Gentoo, as documented at https://ces.mataroa.blog/blog/gentoo-olvwm-bye-ubuntu/).

A survey of available olwvm implementations available on github at the time I created the repo is in the README of https://github.com/olvwm/xview/

Currently this works on an ancient 32-bit laptop (running NixOS 22.05 as documented in https://ces.mataroa.blog/blog/distro_hoppingmd/) as well.

By that metric, my implementation of romforth for x86 clocks in at just 12 bytes (see 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).

I've been faithfully using the same window manager [olvwm] for ~30 years and counting. In fact the decision about which [distro] I pick for daily use is totally dependent on whether it can be coaxed into running [xview]+olvwm.

[olvwm]: https://en.wikipedia.org/wiki/Olvwm [distro]: https://ces.mataroa.blog/blog/distro_hoppingmd [xview]: https://github.com/olvwm/xview

To build minimal linux systems, I've found Minimal Linux Live [^1] and Floppinux [^2] useful. There was a list of build steps for 486 [^3] as well, in case you are targeting older machines.

[1]: https://github.com/ivandavidov/minimal-linux-script [2]: https://github.com/w84death/floppinux [3]: https://www.insentricity.com/a.cl/283/booting-a-486-from-flo...

Something like an automated proof assistant to help annotate the stack while coding would be awesome, but I'm not aware of any.

These might be famous last words, but if switching between compile/interpret modes is ignored, I think it shouldn't be too hard to implement it though.

I have ported Forth to a dozen small microcontrollers and my experience writing much of the bootstrap code in Forth tells me that you are better off coding Forth in a "vertical" style (ie one word per line with stack picture comments), rather than the terse "horizontal" code of "everything on one line" that many of the folks using Forth (including @yosefk, the author) seem to prefer.

Given how close Forth is to assembly (seen from an implementer's point of view) it makes sense to write Forth in a "vertical" style which reflects the "vertical" style in which assembly code is written. This has the advantage that the "stack picture comments" on each line of code can stand in for Hoare triplets so that the code and its - I'll call it - "proof" can be written hand in hand at the same time.

This is how all of the Forth code that I've written in https://github.com/romforth/romforth is structured.

It does make the code appear less compact though so you are not going to win any code golf prizes.