I wrote muFORTH to explore some implementation techniques (a simple native code compiler for the x86, tail recursion), and the idea of building a small kernel, with just enough bits in it to bootstrap itself, by loading more Forth code from source. I started working on it in 2002; in 2005, after unsuccessfully trying to “port” the simple compiler to the PowerPC, so a friend with a Mac could try the system, I rewrote the core to be an odd hybrid of C code and indirect-threaded Forth. Now it is (hopefully) completely portable. The MuforthReadme – though outdated in some ways – is a good introduction to why I wrote muFORTH and what I was trying to achieve. It describes the native-code compiler version of the system. That, and a few other things – notably create/does, the tokeniser, and the lack of tail-recursion in the threaded version – have changed since the MuforthReadme was written, but much of it is still true, applicable, and hopefully of interest. In addition to the stated goal of exploring implementations, one of the primary reasons for writing muFORTH was to replace the very unportable Linux-specific Forth – dforth – that I had been using to do target compilation (for embedded control applications). I’m very interested in writing target compilers, hosted on muFORTH, for the ARM and AVR architectures. I’ve done some of the work already; both are in the master branch of the git repo; see target/ARM/ and target/AVR/. I'm about to launch into writing some support for Freescale's HCS08 as well. Getting the codeThe code is hosted on github - one of several options for HostingGitRepositories. It is possible to browse it there, or (better by far!) to clone the github repo by first installing a local copy of git, and then executing the command: git clone git://github.com/nimblemachines/muforth.git This will create a local directory called muforth/, which, because of git's distributed nature, contains not only the latest checkout of the master branch, but also muFORTH's entire development history. I kept a development diary for a while, but now the best annotated history is the git commit comments, which you can browse (on github), or read (from your cloned repo) using git log or git log -p (if you want to see diffs). Using git takes some getting used to, but for following muFORTH's development it's pretty much trivial. When you feel like it (or when you see on github that new changes are available) simply cd into muforth/ and do git pull This will do two things:
Git keeps branches that follow remote branches (like refs/remotes/origin/master) separate from branches (like master) that you could do local development in. It sounds complicated, but it makes sense and keeps things much cleaner. I heartily recommend using git on projects where you have a choice. Having gone from CVS to Subversion to git, I couldn't be happier, and will never go back. Because conversion is a bit tricky, I wrote a page about UsingGitSvn to get code out of Subversion and into git. Enjoy muFORTH and git! I gave a talk!In March 2008 I gave a talk about bootstrapping, muFORTH, and ConvivialTools. A warning: I wave my arms around a lot, and the audio isn’t that great, but you might find it amusing. Recent posts |