2007 actually. Anyway, ask me anything!<p>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: <a href="https://github.com/nornagon/jonesforth/blob/master/jonesforth.f" rel="nofollow">https://github.com/nornagon/jonesforth/blob/master/jonesfort...</a> 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.
Back in the 1980's I had a TRS-80 color computer which was running a Unix-clone operating system called OS-9, this was multi-tasking and multi-user so I could log into my Coco with a DEC Correspondent printing terminal.<p>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.<p>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.
This is <a href="https://github.com/ruda/jonesforth-macintel" rel="nofollow">https://github.com/ruda/jonesforth-macintel</a> the port I did to Macintosh i386.
Read it once more, and it was a good way to remind me of how fun programming was before we had megabyte libraries and dozens of layers of abstraction.<p>I also noticed something that made me smile:<p><i>"There is no generally agreed syntax for this, so I've gone for the syntax mandated by the ISO standard"</i><p>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.<p>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.<p>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 <i>program in</i> Forth, you <i>write a</i> forth.
How hard would it be to port this to x86_64? Offhand I'm guessing the alignment, register names (eXX -> rXX), changing any relative offset from 4 to 8, and syscall convention. Any other hidden landmines?