Forth: The Hacker’s Language

Nor would I. Even at the age of 8, before I was really able to understand the code, there was a thrill to it, in a cracking-open-the-toy kind of way.

And it helps that Smalltalk does exploration better than just about any other language/environment. You can just open up any Smalltalk app and extend/take it apart using the same tools the developers did to build it.

>There seems to be a sad lack of excellent online communities nowadays; I've long looked for sites to complement HN, but without success.

Lainchan (a sort-of cyberpunk/whatever chan) is quite popular with some of the people who are here on HN. It's a very different atmosphere, but it does emphasize actual good discussion. And it's got a containment board for politics, which always helps.

At the very least, their magazine (https://lainzine.neocities.org) is worth looking at, if not for the generally interesting articles, than for the outright strangeness of a lot of it.

The August 1980 issue of BYTE magazine was all about FORTH. I read it cover to cover, then sent to the Forth Interest Group for a copy of the implementation guide and the 8080A listing of Forth.

I typed it all in, including comments but changed the 8080A mnemonics to Z80 mnemonics. After the typos were corrected and the I/O routines modified to run under TRSDOS it ran as advertised. Then I optimized the code for Z80 which made it both smaller and faster.

My job then took me from Tandy's manufacturing plant to the R&D department where I wrote assembly code for another product but continued to work on Forth as a side project. Management said that they would be willing to release it as a product if I could get a signed statement declaring Fig-Forth to be in the public domain. I tried repeatedly to get people at the Forth Interest Group to sign but was never successful. This is the reason Radio Shack never released Forth, though many people in R&D used my code internally. They especially liked the ease of number base conversion.

From Tandy, I went to an industrial equipment manufacturer where I wrote a lot of assembly for embedded applications. I ported CP/M to run on TRS-80 model 12. The need arose to read input from a graphics tablet via serial, process the input and output a bitmap. My estimate on the length of time it would take to write this for the CP/M machine extended past the deadline.

I combined my Forth code with the drivers for the Model 12. The boot procedure for Model 12's consists of reading 26 128-Byte sectors from Track 0, Side 0 into memory and jumping to the loaded code. I changed to format of the remaining tracks (both sides) to 9 1K sectors and a 256 byte sector (double density). My boot code prompted to press the F1 or F2 key, then read all the 256 byte sectors on side 0 or side 1 (depending on F1/F2) into memory. I added a FSAVE word which wrote memory to the 256 byte sectors. I had a Forth operating system. I wrote the code for the application in Forth, performed the necessary scanning and conversion and output the desired bitmap with time to spare.

I highly recommend learning assembly for at least one processor. Without it, you can only know about Forth, you don't really know Forth. I understand how directly threaded code (DTC) works but I prefer the indirectly threaded code (ITC) model of Fig-Forth as it seems more elegant to me.

I still have an x86 machine running Windows XP which will run the 16-bit code but it will not run on my Windows 7 system. I am looking at ciforth [1] which is a 32-bit implementation. I intend to get it running under Windows 7.

Forth is a really good system for a command line environment. As far as readability goes, the code itself has such high information content that it is difficult. It is up to the programmer to add abundant comments which make reading the code unnecessary in most cases.

I'll conclude with a Forth joke:

: Decompose ROT ROT ROT ;