I’ve started implementing my own FORTH language and posting some screen shots online. I won’t go into all the reasons why I’m doing this apart from saying I miss using FORTH. Now, I’m enjoying “rolling my own”.

Several people have asked if I’ve posted the code. The short answer is no. First, this is more of a hobby project to see if I can do it and how difficult it is to do. Second, being a hobby project, there are no tests, no elegant answers, just code that works. With bugs. It’s a prototype. Will I ever post the code? Maybe. I’m thinking about it.

So, what am I really doing? I’m implementing FORTH in Python. Why Python? It’s fast, it’s iterable, and I don’t need to worry about a tool chain that takes half an hour to “prepare devices”. That means I can code on the iPad, which is what I’m using for this. The code runs remotely on a RaspberryPi, but there isn’t anything to keep it from running on other platforms. I’ve run it on my MacBookPro without problem. That’s why Python is nice. But isn’t Python slow? I don’t know what you’re trying to execute, but anything that runs within half a second is fast enough for most things. I’ll worry if something takes more than 5 seconds. After all, I wait for XCode for ten minutes at times.

Right now, I’ve written about two-thirds of the words for a 79-standard FORTH. Some of these are now actually written in FORTH. So this proof-of-concept works. Here’s the thing. It’s implemented to work, not be efficient, or even based on anything done previously. It’s messy. The most difficult part is memory. FORTH uses raw memory for most things, and most FORTHs are written in assembler. Python, as most languages don’t allow hardware memory access. No, I’m not going to write assembler or ‘c’ calls to assembler. I’m not getting paid to do this. It’s fun for me.

As a side note, I can also create a GUI, call the underlying OS, and even control the GPIO pins on the RaspberryPi. That’s the beauty of Python as an implementation language.

If I can’t use memory, what am I doing? Well, initially, I used a standard Python list (array) of 32K. The problem is it’s not a byte-array. It’s just a list, so each element can hold anything pretty much. It works. It’s inefficient, but it’s simple to program.

I’m ripping out the generic list and rewriting my app to use an array of bytes. Now, Python has a bytearray object, but it’s messy. So, what I’m doing is putting constraints on a Python list to only hold a byte per element. Again, nothing fancy, but simple and it works. The big problem is, now I need to rework most of my logic to deal with this new simulated memory (SM) structure. I need to create low-level memory access routines before I can deal with using them in FORTH. I’m also writing my own memory dump routine. Along the way, I’ll start adding test code.

Two steps forward. One step back.

I also think I need to figure out (read learn) how to use Sphinx to generate documentation.

So, I could post the code, but it’s in a lot of flux at this point. No, I won’t use GitHub. If I post it, it would probably just either a zip file or source listings.

It’s a fun side project. I’m learning a lot about what FORTH does under-the-covers.