Forth Cracks RISC-V

Over the decades there have been many programming languages, some of which have flowered briefly, and others that have stuck around despite newer, better, and faster competition. Few languages embody this last group more than FORTH, over five decades old and still cropping up wherever a simple, elegant, fast, and compact stack-based programming language fits the bill. [Alexander Williams] has now taken it somewhere new, with a FORTH in RISC-V assembly which runs on the GD32 series of microcontrollers that are RISC-V lookalikes of the popular STM32 ARM parts.

We have to admit to last having used FORTH on an 8-bit home computer in the 1980s, aside from a moment’s idle play on discovering that the Open Firmware on Apple computers is a FORTH interpreter. Thus we’re intrigued by this implementation, but not from a position of FORTH expertise. We’d expect such an efficient language to be extremely quick though, so it’s definitely something to keep an eye on for when a suitable dev board comes our way. If it interests you, take a look at the GitHub repository.

48 thoughts on “Forth Cracks RISC-V

      1. But Forth is a great start. I’ve never used it, but reading about it forty years ago, I realized it would make a great monitor. You need some basic things when starting a CPU, and Forth provides that. And potentially, you can write your assembler or Basic interpreter in it. A great way to bootstrap.

        1. Indeed. Its greatest strength – in my opinion – is when firing up a freshly soldered prototype, as Forth allows to interactively examine hardware “from the inside” without demanding much.

          Time to finally try Forth yourself :-)

      2. this is because most forth projects are invisible, i.e. inside embedded products. that is where forth shines. my building automation devices, controllers n io boards has embedded forth using commercial forth called swiftx

          1. Because Forth is easy to mold to your liking and everybody has a better idea and the outer interpreter/compiler is easy to write. Forth forks like crazy.

      3. I hit a wall learning to use C to program microcontrollers, going from programming only to electronics. Everything about the microcontroller was abstracted away with no discoverability and all the interesting projects used arduino C or big opaque libraries. I decided to take a break from trying to read.h files and flashed forth onto one so I could start deeper. Most of what I now know about microcontrollers came from mecrisp-stellaris Forth on the blue-pill stm32f1 boards. The total footprint of the language and libraries are much shorter than with most microcontroller programming setups, making it possible for a beginner to learn by just reading the bulk of the system code. Once you understand what the horrific C libraries are doing and why, it’s much easier to understand them. Forth has other appeals as a language, but one concrete use case is firmware. Very, very few software suites in any language offer a microcontroller programming/debugging experience on par with forth over serial. Making uploading code the same as typing has the benefit that it’s dead simple to write your own integrations with whatever features you want, particularly incremental compilation and partial changes. The quality of life improvements from JeeLabs, especially the cornerstone word, make this even better. being able to store the local copy of code on the microcontroller/board instead of on my computer lets bugfixing go so much faster.

        1. I do the same with C. I start from scratch, with my own libraries. I also work incrementally, except I edit the source file on my PC using modern editor. To run the code on the target, is just a matter of 2 keystrokes and 1 second delay. I don’t see how Forth would be faster.

          1. Jokes aside, I am using modern editors on my desktop machine, too.

            Typing in the terminal directly is useful when something misbehaves and one manually walks through several possibilities to narrow it down. In C, to test a function, one needs to write another function that runs the test and reflash, whereas in Forth, one can pass parameters to anything manually and immediately. You can exchange interrupt handlers without stopping. You can add a definition to try something while running a control loop in another task.

            It has proven useful in embedded in history – it also helps that debugging is possible over any possible connection, even a single LED using the Ledcomm protocol, whereas for C, one usually needs JTAG or similar to gain debug insight using GDB. On less than a wizard level, small things matter. On wizard level, both C and Forth are Turing complete (at least with finite memory).

          2. With the current state of tools, you probably need similar skills to use Forth, since there’s not an easy path for beginners. If there’s no Forth already made for a certain target, with ready made example code, you need to do all of that yourself.

          3. Given that open source Forth is developed mostly by individuals, it already has a nice selection of targets with ready-made binaries available. By no means we can catch up with the huge vendor ecosystems and amount of forum posts existing in C and the sheer amount of chips and peripherals everywhere, but for adventurous beginners, there is Hackaday! Elliot once wrote a tutorial.

            Blue Pill, Longan Nano, Icestick and Pi Pico are supported out of the box, to name popular ones. Well, and then it is time to dive into the datasheet anyway to finish your project…

            Conquering a new target in C, jumping through the hoops adjusting memory maps in the linker script and getting familiar with how to use Picolib isn’t a path with a lot of examples and documentation either. One can usually choose between library driven vendor-lock-in with examples or get familiar with bare metal yourself.

            … there is always an Arduino to get one started while holding hands :-)

    1. Unfortunately Forth is not as much promoted as it should be.
      Mecrisp on RISC-V exists for a few years already.
      When I was involved in Forth, I was missing easy asscess to documentation and explanations.
      And for this reason I started my Forth Bookshelf.
      Many books about Forth in the same place and easy to get hold of in print via amazon.
      And there are books for background and to get started – but nothing about RISC-V yet.
      For example Forth online in Javascript to play with

  1. Congratulations, nice to see diversity in Forth on RISC-V!

    I am the author behind Mecrisp-Quintus, which is also a Forth written in RISC-V assembler, running on exactly the same hardware, and including compiler optimisations like constant folding and register allocation. Forth has been around for a long time, but learnt to fly in terms of performance!

  2. Whenever anything comes up mentioning Forth, somehow I always have the /exact/ same thought…

    “If that’s Forth, what was Therd like?”

    …hey, at least I didn’t claim it was a GOOD thought!

  3. Back in the days when Atari was a powerhouse in the arcade and home computer/console market a good number of their in-house titles were written in Forth, so many of us have played those old arcades and home console Forth based games and not even known it!.

    In fact they even subsequently ‘released’ their version (or maybe it escaped!) of Forth called Coin-Op Forth for the ambitious to write their own software.

  4. Pretty sure a lot of Forth coding is very still alive and well among those little beauties of niche OS design as well. Wanna REALLY know what it takes to learn how low level functions and have a litttle fun while doing it? Check it out:

    Tools are fun too…

    Ever hear of Orca? If you havent and your into music productions geekier side.. like me.. this stuffs not new.. but still fresh in my mind of how awesome the world of coding is when you take it special places. Keeps a hardware ADHD guy interested and inspired to keep doing it here…


  5. I have only dabbled in FORTH. However I have the impression that it uses a few special purpose registers (if the CPU has enough) and then pushes all operands onto a stack or into memory. Would that not very much underutilize a register intensive architecture like RISC-V?

    1. You’re not entirely wrong, but also realize the GD32VF103 has its RAM on-chip, reading/writing to RAM is just as fast as registers. I dabbled with the idea of using a register for the top stack entry, but I found myself doing more stack juggling in the end… because to add to the stack (from the programmer’s perspective) requires you to move the old register data to memory before you can write the new value to that register. In the end you’re still accessing the stack! Hahaha. The (really old) book called “Stack Computers (1981, Koopman)” discusses this exact question and there seems to be no real benefit to using registers that way unless the CPU itself was designed for this Forth use-case (ex: writing to the “top of stack register” automatically pushes the old value to memory in a single cycle). Unfortunately that’s the extent of my knowledge on the subject. I could be wrong.

      1. As always .. it depends. Litterature says you can expect up to 10% speed increase through caching the top stack element (TOS). Caching more stack registers seems to be counterproductive because of necessary uncaching before exiting a Forth word. However all this has become old folklore meanwhile and differs between CPUs. Add to this that some Forths are bytecode interpreters while other Forths compile to native machine code, so that microbenchmarks are like comparing apples with lawn mowers. Knuth said “premature optimization is the root of all evil”. IMO an expected speed increase of just ~10% is not worth the hassle of register caching. When you experience a bottleneck in your Forth programs, profile it, identify the causing sequence of words (mostly within loops) and write some new application-specific primitives in assembler (or C when your Forth is C-based).

  6. The GD32F103 is an ARM knockoff of the STM32F103, while the GD32VF103 is the risc-V version. While one of (if not *the*) first risc-V chips that a regular human could obtain, rumor is production is winding down on them.

    Luckily, the CH32V103 seems to be very similar (supposedly pin-identical and nearly register-identical, which makes sense as they’re both targeting the same chip) and is now becoming available.

    Love seeing new Forth implementations.

  7. Hello fellow Forth and RISC-V enthusiasts!

    I’m late to this conversation but I wasn’t late to getting Forth running on RISC-V! ;-)

    Back in March 2017 I got my hands on a SiFive HiFive1 and proceeded to add support for it to muforth, a “tethered” Forth for cross-compiling to microcontrollers that I have been working on for several years.

    More recently (December 2021) I got some basic serial chat code – the “channel” for interaction between the tethered target and host – running on the Longan Nano (GD32VF103) as well. I haven’t done much more with the board yet, but I plan to!

    I’m also excited about getting Forth onto the Espressif ESP32-C3, another new RISC-V device.

    As other commenters have noted, Forth is a *great* environment for exploring new – or new to you – chips because of its interactive nature.

    Tethered Forths are nice because the “conversational” aspect of the system is implemented on the host, and only the “object” code ends up on the microcontroller, so *much* larger programs can fit in the flash.

    Also, muforth contains its own assemblers and disassemblers, so no external tools or toolchain is necessary!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.