Jonesforth – A sometimes minimal Forth compiler and tutorial (2007)

I want to write one for bare metal (non-Linux) raspberry pi (ARMv6 32 bit on Raspberry Pi 1 and Zero; ARMv7 and ARMv8 on higher models and also supports 64 bit). I want to have no dependencies required though so was thinking of bootstrapping it with nothing but machine code (determined initially with the help of an assembler and documentation of course). Someone has already ported jonesforth the Raspberry Pi[1] but using serial i/o as the user interface and it has dependecies to build it, but I should be able to get ideas from how they coded their assembly parts compared to the original jonesforth. I want to be able to use HDMI for the screen (already tried it out with some bare metal tutorials in assembly so that's do-able) and again, with no dependencies. And I want to show people how to do it themselves, not just have it be something to run that they don't understand fully. It should also be possible to have the forth kernel build/assemble itself if needed, or cross-target another platform.

I know I'm all talk right now, like you say, I need to manage my free time so that I would have the "copious free time" to work on this.

The only reason I was thinking Raspberry Pi was I wanted something that would be readily available to anyone (although, at the moment it's out of stock due to supply chain issues). I was actually looking at whether anything similar was available with RISC-V (like you mentioned) to target, since that would be interesting.

[1] https://github.com/organix/pijFORTHos

On that theme, collapse-OS has a discussion:

http://collapseos.org/forth.html

I just used Jonesforth as a guide/model to write a Forth for the Project Oberon RISC chip last week. It's not finished yet but it works:

https://git.sr.ht/~sforman/PythonOberon/tree/master/item/for...

https://git.sr.ht/~sforman/PythonOberon/tree/master/item/for...

The idea is to make something like (or a port of) CollapseOS, but with a 32-bit machine. The Oberon RISC chip is big enough to be more useful than 8-bit systems yet simple enough that you could build one out of discreet components if you had to. It's really really simple.

See https://bootstrapping.miraheze.org/wiki/Main_Page

> This wiki is about bootstrapping, i.e., building up compilers and interpreters and tools from nothing.

For a different apocalypse poem, allow everything existing to be used, but the coming population collapse demands a full stack replacement. To preserve existing capabilities and progress, but supported by far fewer people.

We've had environments with far greater individual programmer productivity than is currently common. But while forth starts out nicely with simple systems, costs escalate unhappily with goal complexity. Similarly with smalltalk, lispms, prolog, haskell. The perennial "we'll easily do a full-stack rewrite in our wonderful X" efforts... haven't.

Past/current efforts avoid implausible goals, like LLVM-quality compilation has to become a one-person project. Or slather on viability constraints, like must run on M in time T, and be accessible to population P. Or "we don't know how to compile that leverage efficiently and consistently - that paper hasn't been written yet - so you can't have it".

But there are increasingly opportunities to do things differently now, if narrower goals demanded it. Community-wide compilation caches - "it ok that the type proof / bulk code translation / whatever sometimes takes days, it only needs to happen once". Compiler runs spinning up 10000 cloud instances. And so on.

What might it look like, to attempt not merely a bootstrap, but a subsuming breakaway?

When I see "Forth" weirdly capitalized like that, I remember that it is also an English word.

Because forth is an exercise in minimalism, its answer to most features is YAGNI. The coolest thing about it is how easy something as weird as forth maps to the quite different different underlying (register-based) hardware, so you can use a forth to bootstrap something with more sugar.

> Unrelatedly (perhaps) I tried writing some basic software in forth and it was pretty horrific.

It might be instructive to compare FORTH to e.g. the previously discussed language K, which is similarly terse in some ways. It turns out that a few convenience features - including first-class- and higher-order- functions, neither of which really sit well within the FORTH stack-focused model - can make a real difference.

Possibly a variable-length array wasn't a good fit for the problem you were trying to solve.

If you’ve seen one Forth, you’ve seen one Forth.

It is the community that surrounds forth, and the type of hobbyists that are attracted to forth, as well as what they are attracted to.

It’s a bit like saying the only thing anyone ever seems to do with Common Lisp is to make macros which redefine the syntax of language. How frustrating! We’ll if they didn’t want to make use of macros, why were they using lisp in the first place?

Part of the appeal of forth is making your own forth environment. That is the whole answer I think.

Edit: notably there are applications of forth which don’t involve reinventing the wheel, like Postscript and Bitcoin Script. In these domains devs aren’t so likely to engage in this activity.

It is not the only thing, but rather the first thing that people often write. There is nothing particularly wrong with that, as forth is the kind of language where intimate knowledge of its internals is quite useful, perhaps even necessary, while simultaneously being easy to obtain (e.g. by writing your own forth). And of course, the number of people who complete one project is necessarily greater than or equal to the number of people who do more than one project.

The last thing that causes the phenomenon you describe to happen is likely the culture around forth, likely as a result of the relative ease and utility of making domain-specific abstractions compared to general abstractions in forth. The community seems to not appreciate libraries and reusable code to the same extent as other ecosystems, preferring instead to share ideas, which each developer can then adapt to fit their particular project in a very minimalist manner instead of adopting some convoluted general solution.

Absolutely not true. Sometimes you implement a lisp in it and from there whatever you want, but usually the next step is some OS.

I've made a Forth dialect and uses it for somewhat specific stuff. I have a program that works for me 24/7 and that I have tweaked and adapted to the evolution of my needs for a decade.

It would be a PITA to strip it from its business-related stuff in order to publish it, so you will probably never see it online. I guess it's the same for other "serious" users.

> Unrelatedly (perhaps) I tried writing some basic software in forth and it was pretty horrific. Even something as simple as representing a variable length array feels like fighting the language

Yeah, don't fight the language, that's the key. And don't do stuff because that's what every other language is doing. "Solve the problem you've got!" Moore said. It could seem dead obvious, but it's actually difficult to prevent yourself from trying to solve problems you think you will have tomorrow, or from solving problems others have.

More specifically don't try to avoid using Forth variables because they are global and you've been taught that globals are absolute evil madness that eat kitties for breakfast. Instead, pick perhaps a couple of values that travel everywhere, causing "stack juggling" in your program, and make them global variables. Maybe hide those global variables behind regular words if you really really really intend to reuse parts of that program.

But really, solve the problem you have now. This also means you should make programs that will actually be useful for you. It can be difficult because this generally involves complicated stuff like connecting to a web server or GUI. Just be pragmatic and use native libraries (or whatever you can find that looks decent, gets the job done, and can be used by the Forth system you're using) to deal with the complicated crap others have been doing for decades. Forth hates complexity, any cheat is fair game.

Here is some interesting Forth software, including a Space Invaders game and an IP networking stack including IP, ARP, UDP, DNS and DHCP [1]. It runs on the J1 custom Forth CPU built on an FPGA [2]. The author says it was originally designed to run an array of Ethernet cameras on a robot.

1. https://www.excamera.com/files/j1demo/docforth/

2. https://www.excamera.com/sphinx/fpga-j1.html

Edit - also mentioned here by adastra22, I see.

I would recommend going the other way as it will probably be easier to appreciate both that way, just from my own experience both learning and writing interpreters for both.

Lisp is sort of the next step after Forth if you ask me, adding slightly more syntax to get better abstractions.