Richard Jones

I feel like this might still be too high level. A better approach may be to teach by the example of writing a basic FORTH environment from machine instructions, then basic helpers written in the language, and working up from there.

Various types of better things can be added in once there's something to optimize.

Edit: I was probably thinking of this version that I likely read a couple years ago:

https://news.ycombinator.com/item?id=13505285

Quoting their post

""
rwmj on Jan 28, 2017 [-]

This is a how-to-write-a-FORTH tutorial that I wrote a few years ago. It's particularly nice that you get to see how various control structures are implemented, like IF, CASE and even comments!

Part 1: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth.S

Part 2: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth.f

(github mirror: https://github.com/AlexandreAbreu/jonesforth/blob/master/jonesforth.S https://github.com/AlexandreAbreu/jonesforth/blob/master/jonesforth.f )

Previous HN comments: https://news.ycombinator.com/item?id=10187248

""

The immediate reply covers my feelings for how the __introductory__ class should proceed: minimal assembly and maximum programmer clarity.

""
rsaarelm on Jan 28, 2017 [-]

Working through Jones Forth got me up to speed on both understanding how Forth works and getting my hands dirty with some practical assembly coding.

Once I got a better idea of Forth, I also realized that Jones stays in assembly for rather long. He…

I think JONESFORTH is awesome, I really enjoyed reading it, and I really appreciate you writing it, but there are a couple of points that could possibly be described as above, but maybe will sound a little less insane if described in full.

• Your ROT originally was backwards. That is, rather than rotating the third element on the stack to the top, it pushed the top stack element down by two items, which is traditionally called -ROT. While obviously this is a purely arbitrary convention, and irrelevant to just trying to explain how Forth works, it did create unnecessary confusion; it means that anybody who actually learned Forth from JONESFORTH would constantly be struggling to remember which way ROT worked. I apologize for never properly reporting this to you. You fixed this in http://git.annexia.org/?p=jonesforth.git;a=commit;h=dccbff0e169d5467a78be5c6d935fa505f6a029f

• The design of JONESFORTH (last time I read it) doesn't accommodate CREATE DOES>, which is the Forth way of creating functions that have state — closures, if you will, or objects with a single method. This, by contrast, I think really is relevant to trying to explain how Forth works. The techniques that support CREATE DOES> (ITC, DTC) are no more complex than JONESFORTH.

I think comp.lang.forth people were slamming JONESFORTH not because of anything about JONESFORTH but because they are mentally insane. (Although I can't really find the flames you were alluding to. The worst I found is complaints…

How do you prepare and how long do you ought to spend preparing the talk? I'll quote `techtalk-pse`[1][2]:

[quote]

First, most important rule: Before you start drawing any slides at all, write your talk as a short essay.

This is the number one mistake that presenters make, and it is partly a tool fault, because PowerPoint, OpenOffice, even Tech Talk PSE, all open up on an initial blank slide, inviting you to write a title and some bullet points. If you start that way, you will end up using the program as a kind of clumsy outlining tool, and then reading that outline to your audience. That's boring and a waste of time for you and your audience. (It would be quicker for them just to download the talk and read it at home).

A good talk, with a sound essay behind it, well thought out diagrams and figures, and interesting demonstrations, takes many hours to prepare. How many hours? I would suggest thinking about how many hours of effort your audience are putting in. Even just 20 people sitting there for half an hour is 10 man-hours of attention, and that is a very small talk, and doesn't include all the extra time and hassle that it took to get them all in one place.

[/quote]

[1] https://en.wikipedia.org/wiki/Tech_Talk_PSE

[2] http://git.annexia.org/?p=techtalk-pse.git;a=blob;f=techtalk-pse.pl;h=b49591;hb=HEAD#l869

Forth is super cool for embedded work. The normal dev cycle of build, burn, not work, tweak, build, burn, repeat is quite slow and annoying. It was kind of revolutionary for me to discover Mecrisp[0], which demonstrates how can provide a (fast!) language that also provides a friggin' repl into your hardware.

The ##forth IRC channel on Libera is quite active. Would recommend popping in for anyone interested. The two projects that got me interested in Forth are

1. JonesForth: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth.S;hb=HEAD

Explanation and motivation for the What and Why of Forth and its implementation. Well, actually, it's actually an implementation in x86 assembly, but the comments are a wonderful exposition and intro into Forth.

2. SmithForth: https://dacvs.neocities.org/SF/

Implementation of Forth in x86-64 opcodes. It's a hand-written ELF that implements a Forth. It's simplicity is absolutely beautiful.

SmithForth is what pushed me over the edge to really start learning x86 assembly and Forth. I started by hand-decompiling the SmithForth binary, which was quite an adventure on its own.

[0]:https://mecrisp.sourceforge.net/

It would, except that the JVM is short a stack -- Forth really likes having two. A Toy Forth is a great next step after writing a Toy Lisp. It's like exploring an alternate universe, where any sort of abstraction between you and the hardware should be knocked down in the name of simplicity.

A few great places to get started:

- Forth Warrior, a programming game using a java-based Forth machine with 2d sprites.

- Jones Forth, a literate x86 forth implementation (great for learning plumbing)

- Retro Forth, a minimalist little virtual machine and Forth image that targets it.

None of these are ANS Forth / FIG Forth / etc compatible, which I think is in keeping with Moore's tradition of just whipping up a new dialect whenever he has a new problem domain.

[1]: https://github.com/JohnEarnest/Mako/tree/master/games/Warrior2

[2]: http://git.annexia.org/?p=jonesforth.git;a=blob_plain;f=jonesforth.f

[3]: http://retroforth.org

The most interesting for me was the comment:

"I actually have a project that uses iopl to provide shell script access to ioport. Yes, you can write device drivers in shell script ...

http://git.annexia.org/?p=ioport.git;a=summary
"

And there in README:

"At first glance it would seem that /dev/port would be the best way to
access I/O ports. However /dev/port under Linux is fundamentally
flawed because it only allows byte-sized access to ports. For example
if you write a single long (4 bytes) it will turn that into 4
individual outb operations.

Instead we use iopl(2) to raise our I/O privilege level so that we can
do the correct in<size> and out<size> operation as requested."