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].
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.
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.
"..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.
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.
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
"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. "
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?
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.
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.)
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
[1] https://www.bradrodriguez.com/papers/
[2] http://www.ioccc.org/1992/buzzard.2.design
[3] https://archive.org/details/R.G.LoeligerThreadedInterpretive...