The project comes in two parts. The first part is linked above. The second part is written in FORTH -- or rather, a subset of FORTH initially that builds up and adds features as it goes along: https://github.com/nornagon/jonesforth/blob/master/jonesfort... Try scrolling down the file, and notice how the comment syntax changes from \ (backslash) to (...) (parentheses), then notice that parenthesis-comments are implemented just before the style change. There's a lot more stuff like that, although that's the most noticeable thing for beginners.
Maybe by chance you even have the source? It seems to have disappeared from the net, together with Gitorious, and the original author is unavailable.
To think again, shouldn't a modern C/C++ compiler be able to produce better code than this assembly without the intrinsic unportability? Let's take, e.g. SWAP
defcode "SWAP",4,,SWAP
pop %eax // swap top two elements on stack
pop %ebx
push %eax
push %ebx
NEXT
/* NEXT macro. */
.macro NEXT
lodsl
jmp *(%eax)
.endm
In general you shouldn't expect FORTH to be fast -- it uses the stack far too much and the way it does branching kills branch prediction on modern CPUs.
However it is very small and a lot of fun to write. If you are looking for a system that can run on baremetal and where you can completely understand the system from top to bottom, then that's FORTH for you.
Compared to C, FORTH has an extensible syntax and features like exceptions. Compared to FORTH, C is a lot easier to write significant programs in.
http://www.lshift.net/blog/2007/10/04/jonesforth-ported-to-p... https://github.com/M2IHP13-admin/JonesForth-arm https://github.com/phf/forth https://github.com/organix/pijFORTHos
I wrote a FORTH implementation for the 6809 in about 3k lines of assembly code which included the language plus the 'standard library'. Instead of the 'standard' Forth I/O, there was an interface to Unix-style file-handle based I/O. It used subroutine threading so that FORTH compiled directly to 6809 code and the part that did dynamic dispatch used self-modifying code to shave off a few cycles.
FORTH is an interesting part of the story about why LISP didn't take off on 1980's microcomputers, partly because if you wanted a LISP on an 8-bit micro, you could get much of the way there with FORTH in a footprint even smaller than BASIC.
I also noticed something that made me smile:
"There is no generally agreed syntax for this, so I've gone for the syntax mandated by the ISO standard"
You won't read that in the source code of a C, pascal, or Fortran compiler, and there basically is only one forth standard, but historically, many implementations know better than to follow it. That is both a good and a bad thing.
On the plus side, it is extremely flexible, but the price one pays for that is that there is barely any code reuse because every system is different.
For systems on which Forth shines, that isn't a problem. There, you do not include that 400 byte floating point library "as is", but take the source, remove the 2% of it that you do not need, and tweak a few calls to make them smaller at the price of performance because you don't have 400 bytes to waste on a bloated floating point package. You don't program in Forth, you write a forth.