A Dynamic Forth Compiler for WebAssembly | Hacker News Reader

A Dynamic Forth Compiler for WebAssembly

el-tramo.be

91 pointspjmlp17 comments

I'm always impressed on the new ways and places that people get new versions of FORTH installed and rolling. I know that eons ago I did one by coding it into 8051 assembler. It was interesting to browse the Webassembly to see if I could match up with what I remember.

Bonus for writing the core in Webassembly, but then writing some of the more tedious parts in Racket.

I was really impressed with the speed metrics. I would have guessed that it would be much faster than a JS version, but would have never guessed on those low numbers.

Congrats on a very cool project!

But forth is a very low level language isn’t it? Even though it’s interpreter, it’s naturally going to be a lot faster than JS and even Java because it maps very closely to the assembler instructions you would normally write by hand. So it would be probably 3x slower than C assuming every Forth instruction takes three C instructions to run (get opcode and arguments, do operation, push on stack).

I have no idea how FORTH stacks up (haha) to other languages on modern machines insofar as speed is concerned. Modern FORTH is compiled so the difference may be quite less than the 3x you are proposing.

On older machines, you will find published benchmarks showing FORTH to be 10 times slower than assembly. Compare this to BASIC which was usually 30-40 times slower than assembly in the best bases.

I think your 3x speed difference between C and FORTH to be on the ball for these earlier machines.

The other advantage of FORTH on these old microcomputers/microcontrollers is that threaded code tends to be quite compact, so you can write larger programs. Efficient use of memory was tantamount on old machines and controllers.

It greatly depends on your forth compiler. Most hobby forth compilers are simple, and just lay down addresses to words or native call instructions, sometimes with inlining. These aren't slow, but they won't get close to C optimized by modern compilers.

Production Forths like SwiftForth apparently have optimizing compilers, but I've never used them.

I wrote jonesforth which is a simple threaded FORTH (in other words, interpreted and certainly not a modern FORTH). Threaded interpreters produce compact code. They are not efficient on modern CPUs, because they interact badly with branch prediction. For embedded cases where memory is at a premium and you usually have a simple CPU like an Arduino, FORTH is a great fit still.

Modern FORTHs are all compiled (as indeed are modern Javascripts). In my view FORTH is a pretty horrible language to write code in, and if you lose the advantage of the compact code for the embedded case then you might as well use a nice compiled language - whatever is your preference, but my preference would not be FORTH if I had to write code all day long in it.

I wonder if the same semantics that make Forth simple and fast can be used with another (higher-level) syntax to make it easier to write in, kind of like how C replaced Assembly. It could become a new family of languages that might rival modern high-level languages in the same way CL Lisp tried to shake things up by being both low-level and high-level at the same time.

You might be interested in looking up concatenative languages. There's a wiki[0]. I really like Joy in the abstract sense.

Factor made a few waves a decade ago but has kind of lost steam[1]. It's still being developed though[2]. Kitten looks promising but develops at a snail pace because it's one guy doing it[3]. Not a dig against him, mind you!

[0] http://concatenative.org/wiki/view/Front%20Page

[1] http://factorcode.org/

[2] https://github.com/factor/factor/

[3] http://kittenlang.org/

Jonesforth is a great tool when trying to teach people how stack based interpreters would work. I used it as an example in a class that I taught.

The documentation is first rate with exact descriptions in the code.

As far as the FORTH being a horrible language, to some extent it is. But if you are stuffing into a small chipset it's good. Granted there are things like Lua now, but back in the early years, FORTH was a huge tool for imbedded systems.

I look at Forth as a great portable assembler in which to write another expressive language (e.g. a Lisp or Smalltalk) in.

I knew someone would make a native FORTH for WASM the moment I heard of the latter's existence. Surprised it took so long for one to pop up, honestly!

Looks like the code is handwritten in the webassembly assembler language [1].

[1] https://github.com/remko/waforth/blob/master/src/waforth.wat

Kind of, WebAssembly doesn't support macros.

He is using Racket.

Forth never got the traction or appreciation that it deserved. It's the only REPL language I know of that can fit comfortably within the storage, CPU, and power limitations of an embedded system.

If more EEs had experience with REPL languages, they'd know what they're missing, and things probably would have turned out differently. His use of Scheme was not a surprise.

Thank you for fighting the good fight Remko.

At least on my degree, CS and EE had common Prolog classes.

Our Prolog class was more like a drive-by math exercise than programming. I don't recall if we actually ever ran anything.

For that we used Tarski's World in introduction to logic classes.

Prolog classes were actual programming with SWI Prolog.

Additionally there are national competitions between universities in logic programming, with Prolog as the official language.

Great!

Reply on news.ycombinator.com