For those trying to grok Forth implementation, I cannot recommend Brad Rodriguez' "Moving Forth" [1] series enough. But my favorite one is "1st, 3rd and almost 4th" [2]. Oh, and Loeliger's classic book on the subject [3].

[1] https://www.bradrodriguez.com/papers/

[2] http://www.ioccc.org/1992/buzzard.2.design

[3] https://archive.org/details/R.G.LoeligerThreadedInterpretive...

There should be a book (or comedy skit) about the people who use Forth, called "Who's on FORTH?"

What are you asking me for??? I don’t know!!!

https://www.youtube.com/watch?v=kTcRRaXV-fg

Jonesforth is insanely cool. The linked mirror seems to be missing 'jonesforth.f'. Maybe try check out this one[1] for the full implementation.

I recently tried porting Jonesforth to UEFI[2], so I could run it directly on my hardware without needing an operating system. I was actually surprised by how easy it turned out to be.

Okay, admittedly I ended up rushing a bit towards the end, and the final result is very bare-bones - it can do "Hello, World!", Fibonacci numbers, and then that's pretty much it. Still, it was a lot of fun, and I would totally recommend a project like this, especially if you don't usually work with "low-level" development.

I also ended up writing a blog post[3] to help people get started writing assembly for UEFI. The best resource is probably the OS Dev wiki, though. It has a ton of great resources.

[1]: https://github.com/nornagon/jonesforth

[2]: https://github.com/c2d7fa/jonasforth

[3]: https://johv.dk/blog/bare-metal-assembly-tutorial.html

[4]: https://wiki.osdev.org/Expanded_Main_Page

Is jonesforth singlethreaded or does it utilize all available cpu cores? I only ask because a lot of these little baremetal languages just do the bare minimum needed to boot to a repl without exploiting the full capabilities of the hardware

It's single-threaded because it's a learning tool not a forth you'd ever want to use in an environment where performance would matter. Single-threaded or not, forth interpreters [not compilers] have terrible interaction with branch prediction - they will never perform well on modern CPUs. Virtually every other instruction executed is a jmp that cannot be predicted and thus will collapse the pipeline.

> forth interpreters..have terrible interaction with branch prediction - they will never perform well on modern CPUs.

Interesting statement. It led me to this paper:

Branch Prediction and the Performance of Interpreters - Don’t Trust Folklore (2015)

https://hal.inria.fr/hal-01100647/document (pdf)

"..Many studies go back to when branch predictors were not very aggressive. Folklore has retained that a highly mispredicted indirect jump is one of the main reasons for the inefficiency of switch-based interpreters."

"The accuracy of branch prediction on interpreters has been dramatically improved over the three last Intel processor generations. This..has reached a level where it cannot be considered as an obstacle for performance anymore."

There is an older paper by Anton Erl that already showing variations in performances for the same implementation technique from one generation of Pentium to another and of course between AMD and Intel.

Personally, I stopped worrying and used the most convenient implementation for my use case (portable interpreter written in C). Your set of primitives and how you code your Forth programs usually have a much larger improvement potential.

That paper refers to interpreters in the traditional sense. However threaded code is not interpreted in the same way. After every instruction is a computed jump. There are benchmarks on this in the jonesforth code you can actually run and you will observe the exact problem there.

Note that the paper does compare a switch-based dispatcher to a computed-goto version ('jump threading') - cf figure 2. The latter used to have a significant performance advantage over the former, which is apparently no longer true (cf figure 3 (a)). That of course doesn't invalidate your point.

> they will never perform well on modern CPUs

Is this statement for indirect threaded Forths only? What about direct threaded, token threaded and sub-routine threaded Forths?

So basically the opposite of APL.

Any language that arranges data in arrays or large structs does well on modern machines, especially with vector and SIMD extensions. To be fair to Forth, there exist machines that are well-suited to running "threaded code"[1], it's just that they are not machines that are commonly available today.

[1] "threaded" has nothing to do with multithreaded: https://en.wikipedia.org/wiki/Threaded_code

I don't buy this. I understand the use of your term 'threaded', but these are unconditional and therefore can be incorporated into the instruction pipeline with little or no overhead. Here's a very old SO post, CPus won't have got worse since then

https://stackoverflow.com/questions/5127833/meaningful-cost-...

"But in general, on modern processors, there is minimal cost for an unconditional jump. It's basically pretty much free apart from a very small amount of instruction cache overhead. It will probably get executed in parallel with neighbouring instructions so might not even cost you a clock cycle. "

If they were all unconditional, that would be fine. The problem is they are all computed jumps (see jonesforth for details).

I see what you're getting at now, thanks

Thanks for the link, that looks really interesting

UEFI forth sounds like a really cool project. Also cool to learn FASM has an easy way to generate efi executables.

I had my third go at Forth this year and I can say it finally clicked, to the point that I ended up buying a license for a commercial compiler for non trivial stuff.

If I may hijack this conversation: I'll be trying T3X [0] next, and know about the usual suspects B, BCPL and MCPL. They seem fun but not as malleable as Forth. Can HN recommend other (don't care if obscure) typeless programming languages?

[0] https://t3x.org/t3x/index.html

I've always been really, really curious about the GA144 devkit for a while: http://www.greenarraychips.com/home/products/, http://www.greenarraychips.com/home/documents/greg/DB014-190...

The only small caveat is that it's basically $500 for a PCB with two chips on it. (And a prototyping area, SRAM, an Ethernet PHY, SD, and USB...)

I'll probably continue to remain curious for some time, heh.

Which compiler, and for what purpose - did you end up buying? What does it give you beyond the many open implementations?

On a side note - anyone know if greenarrays is still delivering hw? Those multicore forth chips really seemed nice (and crazy).

Mostly performance. GForth is slow compared to the optimising compilers (I know about gforth-fast already). Also I don't care that much about open source. I'm old enough not to be opposed to the idea of buying compilers.

I ended up with iForth which is well priced, targets 64bit and has a simple license. Here's a feature list http://users.bart.nl/users/mhx/i4faq.html

SwiftForth and VFX are awesome as well but 32bit only and can't justify paying that much at this point.

Hm, I hadn't really thought about optimizing compilers for forth... I wonder if the strategies are different than for eg c or Pascal compilers.

I guess the situation is simalar for other closed compilers (Intel c, high perf Java compiler/VMs etc).

On Linux you will encounter:

    jonesforth.S:1154:10: fatal error: 'asm/unistd.h' file not found".

Here is the solution: https://stackoverflow.com/a/53686051/198927

Struggling to get this so build on OSX, so I've posted a question on SO: https://stackoverflow.com/questions/61077637/how-to-compile-...

Funnily enough for something that's made such a huge impact on my life, I never managed to get Jonesforth to compile either. It's such a good read that it hardly matters whether you actually run it. (Instead I used it as the basis for a FORTH-83 implementation in Julia and ran that instead.)

This port of JONESFORTH compiles on OSX: https://github.com/ruda/jonesforth-macintel

Wow. I love the license: "I, the copyright holder of this work, hereby release it into the public domain. This applies worldwide.

In case this is not legally possible, I grant any entity the right to use this work for any purpose, without any conditions, unless such conditions are required by law."

I wonder if that is good enough. I'm temped to use that for my extremely permissive stuff.

I copied that from Wikipedia (back in 2007 obviously) public domain release statement, which is written by a lawyer so I've no reason to believe it's not watertight, at least in the US. The intent is to make it public domain, but unfortunately you can't "place something in the public domain" in most jurisdictions, contrary to popular belief. Therefore you have to provide the back-up extremely liberal license. Nowadays as others have said you'd be better off using CC0.

Specifically to make it "good enough", CC0 was created:

> CC0 helps solve this problem by giving creators a way to waive all their copyright and related rights in their works to the fullest extent allowed by law

https://creativecommons.org/share-your-work/public-domain/cc...

CC0 is another way to do it, much wordier, but with legal advice behind it: https://creativecommons.org/share-your-work/public-domain/cc...

I still like the JonesForth version of a public domain release.

Really beautifully written and documented code!

https://github.com/nornagon/jonesforth/blob/master/jonesfort...

We changed the URL from http://git.annexia.org/?p=jonesforth.git;a=blob_plain;f=jone..., by the request of Forthjones himself, whose home server was being pummelled.