FiveForths is a tiny Forth written in hand-coded RISC-V assembly, initially designed to run on the 32-bit Longan Nano (GD32VF103) microcontroller.
This document provides an explanation of FiveForths and the story behind it.
Most likely, every Forth creator in this millenium has faced this question. I've already blogged about my decision here and here. To resume, I think Forth is a nice way to start fresh in the world of microcontrollers and FPGAs. I think if we want to go back to owning our tools and creating things that run the way they should, then we need to start from a good minimal base.
My initial goal was to start from derzforth by contributing to the project and help bring it to a fully useable implementation, but I eventually decided to create my own which was more aligned with my personal goals.
I want to use FiveForths as an alternative to my current C++/Lua-based microcontroller projects. I also want to use it as a building block for deploying to larger RISC-V instruction sets (ex: 64-bit) on much more powerful devices. Eventually, like most dreamers, I'd like to create an operating system or something like that, so I guess I had to start somewhere.
Those who know me are aware that I've been programming in PicoLisp for almost a decade. It's been my go-to language for almost everything at the high level, but I've been unable to get it to lower-level microcontroller projects. In the end, I'm not even sure that Lisp (of any kind) is suitable for a microcontroller.
At the start of 2023, I wrote about what kind of threading I planned on using (direct-threading), but the implementation was ugly and buggy, so I switched to indirect-threading shortly after. The implementation is very similar to existing implementations such as jonesforth, so it was very easy to get it working perfectly and it's also easy to reason about.
I'm aware that it may have some disadvantages on a modern RISC-V CPU architecture, but it's something that can eventually be changed if I start to notice some performance issues, and if I have time to work on it.
A typical Forth will have a variable word length for dictionary entries. The header that's built in memory would then store the word length and the characters of the word, and add padding to words for it to align on a boundary (ex: 4 byte boundary). A 32-character word header would end up requiring 11 CELLs of memory compared to a hash which would only require 3 CELLs for the header.
The disadvantage of hashing is the number of cycles required to compute the hash. We're looking at an order of magnitude more time, but on a Longan Nano running at 8 million cycles per second (8 MHz) it's still blazingly fast.
Considering the relatively small memory size of the Longan Nano Lite (20 KBytes), I feel like it would be a massive waste to use nearly 3x more memory by storing words the traditional way. Since it can be also be clocked up to 108 MHz, it seems much more sensible to focus on optimizing memory usage rather than optimizing the code execution path.
FiveForths only has 19 built-in primitives, which is at least 150 less than a typical Forth. This means to get a "real" Forth would require writing (or pasting) hundreds of lines of code into the terminal. Keeping with the idea of having an extremely minimal implementation, this approach seems fine for me. Not all primitives are needed for every use-case, and this allows the dictionary to be built specifically to suit ones needs.
Now that you've read the answer to various questions, you're ready to read the other documents below:
- TUTORIALS: a quick guide to get started
- HOWTO: build, usage, and code examples in Forth and RISC-V Assembly
- REFERENCE: learn the technical details, what's under the hood
FiveForths documentation and source code copyright © 2021~ Alexander Williams and licensed under the permissive open source MIT license.