Hacker News Reader

Comment by alexisread | Hacker News Reader

OOI, this bytecode VM uses 30 instructions while something like Freeforth has 55 forth instructions- is it actually worth having a bytecode VM under the forth VM?

Arguments for are that you could migrate processes easier, and I/O has a std interface. But against that it's not native code.

I'm struggling with defining the instruction set for my own forth-style VM.

View on HN

I think the instruction set, or the minimum number of primitives you need to implement in the "host" not the language itself is fascinating.

I've looked at a lot of implementations that have a DROP definition like this, for example:

    : drop ( x y -- x ) dup - + ;

That works UNLESS your stack has only a single value on it. Things like this get simpler if you have a variable pointing to the top of the stack where you can just change that - but otherwise you end up having to implement DROP as a built-in.

You can obviously implement "<" in terms of ">", and if you can multiply by -1 you can implement subtraction in terms of addition, but at the same time writing "-" is no harder than writing "+", if you're not targeting a small CPU like a Z80.

I love to compare implementations, to see which core primitives they've chosen, and explore the consequences. These days I think my interest is more in implementing FORTH than actually using it, but I suspect I'm not alone in that regard!

Agreed, the implementation is the fun part!

Obviously instructions can be chosen for efficiency, else we'd all be using the 7 instructions of sectorforth. In fact freeforth has additional instructions for register renaming (to avoid SWAP instructions).

So what's a good set? Most seem to have 25-30 (Mako, Retro, Jones, Stoneknife)

> Most seem to have 25-30 (Mako, Retro, Jones, Stoneknife)

Know of any good sources that catalogue these? If it's all in your noggin I respect that, but had to ask.

Not any sources/overview as such, I just looked at the VM code.

So for Mako: https://github.com/JohnEarnest/Mako/blob/master/src/MakoVM.j...

Freeforth: https://github.com/dan4thewin/FreeForth2/blob/master/ff.asm

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

Stoneknife: https://github.com/kragen/stoneknifeforth/blob/master/tinybo...

Retro/Ilo: http://ilo.retroforth.org/ilo.txt

Sectorforth:https://github.com/cesarblum/sectorforth/blob/master/sectorf... but see: https://github.com/cesarblum/sectorforth/issues/6 and: https://github.com/cesarblum/sectorforth/issues/8

I think of Retro to be the "gold standard" for various reasons so I'd lean to the 25-30 mark.

I believe can be as few as three

https://pygmy.utoh.org/3ins4th.html

I'm not sure I'd quite count this as Forth; it's more of a very simple monitor for loading and running code. It's not a bad approach for use with a host Forth though.

Reply on news.ycombinator.com