Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
RetroForth 2021.1 (forthworks.com)
132 points by mindcrime on Feb 17, 2021 | hide | past | favorite | 52 comments


I first came across retroforth back in 2001 when it was originally being developed by tcn. Later crc picked up the maintenance and development of it and did a stellar job with it.

Retroforth was my favorite forth in linux because it was the most accessible & usable & cross-platform forth that adhered closely to the spirit of Chuck Moore's original (pre-color) forth, rather than the ANSI standard.


A different Forth I enjoy to hobby code puzzles in is [Factor](https://factorcode.org/) and is probably an easier place for people to start. Forths are wonderful languages that everyone should have some exposure to, they are like a cross of Lisp and Smalltalk. You should definitely try it at least once.


The difference is that Forth compilers can be bootstrapped from not-very-much assembler on an embedded system. That's not really true for Lisp and Smalltalk. Forth impresses me because of the degree of leverage that bootstrapping process affords for small computers.


> Forth compilers can be bootstrapped from not-very-much assembler on an embedded system. That's not really true for Lisp and Smalltalk

Sectorlisp[0] is an attempt to make a lisp that can fit in a bootsector (512 bytes). It's currently ~1.5 bootsectors; larger than the smallest forths, but certainly in the same ballpark.

Stage0[1] is an attempt to make a boostrappable seed from a minimum of binary dependencies. I recommend taking a look at what it says[2] on the matter, though it's too long to quote here.

0. https://github.com/jart/sectorlisp

1. https://savannah.nongnu.org/projects/stage0/

2. https://git.savannah.nongnu.org/cgit/stage0.git/tree/README.... skip to ‘stage2’


I think that very much depends on the Lisp in question. Even if you want a Scheme style Lisp which really needs some form of GC, you can implement a very rudimentary one using bump allocation. Basically just allocate memory by bumping the stack pointer and clear out everything at specific boundaries (i.e. you have some memory that is fixed at startup with the interpreter, basic functions, and constants but after that have well defined points where you clear out everything).

If you want something closer to assembly, you can just use a normal Lisp and have the Lisp compile itself to an assembly program, but with the benefit of things like variable names whatever other abstractions you can come up with. This approach is taken by Fairlylog[1] which is implemented in Racket but produces Verilog. You are basically writing a new language which compiles to assembly, but with the benefit of better tooling. Racket gives you the benefit of things like syntax-parse for writing the parser in a way that gives good error messages and more flexibility than a parser generator.

[1]: https://pkgs.racket-lang.org/package/Fairylog


> just allocate memory by bumping the stack pointer and clear out everything at specific boundaries

You've described region-based memory management, also known as arena allocation. [0] This can indeed work nicely in short-lived applications like missile-guidance and even serious compilers. [1] It's not real garbage collection though.

[0] https://en.wikipedia.org/wiki/Region-based_memory_management

[1] https://web.archive.org/web/20190126213344/https://www.drdob...


> Forth compilers can be bootstrapped from not-very-much assembler

Do you have any resources handy on how one could do that from scratch?


A good learning resource is Jonesforth (something of a classic), on GitHub here: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

I wrote several Forth compilers when learning to code as a teenager, one using the A86 assembler, and two fully bootstrapped-from-assembler ones for 8086 and 386. The 8086 source code is here (I didn't write the assembler myself): https://github.com/benhoyt/third (KERNEL.F has the assembler parts)



Nice find. Thanks.


Jonesforth [1] is a classic example of this, and a really good example of “literate” code.

[1] https://github.com/nornagon/jonesforth/blob/master/jonesfort...


I did this for the TMS34010 graphics processor many years ago but my notes are long gone. I was inspired by Mach 2 Forth, an amazing compiler for the early Mac. My compiler had local variables and tail call detection to take advantage of a special "one-deep" stack register on the chip.

The key point is that Forth can easily incorporate an RPN assembler which you can write in Forth, and with which you can then build a better Forth. I'm not sure if I even started with the official TI assembler for the chip; I probably first wrote a cross assembler in Mach 2 by transcribing the ISA manual and bootstrapped from that.


You requested from scratch, but also look into "metacompilation", which was typically how it was done.


Forth is sort of live image like Smalltalk, and great for designing languages/DSLs in like Lisp which is also homoiconic.


Lisp surely can and has been.

Basically start with a s-exp based Assembler, add a macro support subset and go from there.


I'd like to see that or maybe try it myself but that's not quite the same as Forth fitting in a 512 byte boot sector[1] or on a tinyAVR. I bet it can be done but I suspect it'd require more cleverness than doing the same with Forth.

1. https://news.ycombinator.com/item?id=24604457


People tend to forget that Lisp was originally developed on an IBM 704, written in Assembly, with the traditional size a 1950 machine filling a server room was capable of, which was just a few KB.

While not the same thing, you can have a look at http://www.ulisp.com/ for AVR.


All the original compilers like Lisp and Fortran were written in assembler. But that doesn't mean it was easy, or that the resulting language was very capable by modern standards. The thing about Forth is that it is easy, and you get a full-featured Forth when you're done.

That's not to say it can't be done in Lisp but Lisp needs a lot more runtime support than Forth. If I was going to bootstrap a Lisp, I'd bootstrap a Forth first and then write the garbage collector for Lisp in Forth.


Writing primitives like cons, car and cdr in assembler, a garbage collector in assembler, and eval in assembler would make a great amount of sense, from a performance and bootstrapping POV.

A Lisp compiler in assembler is just about rationally unjustifiable, though.


I think this tech talk on Factor offers a pretty good tour of the language.

https://www.youtube.com/watch?v=f_0QlhYlS8g


If my aim was just to learn, what would be the advantages and disadvantages between gforth, retroforth, and factor?


I did not find gforth or factor to be very easy to get up and running with.

If you want to learn forth concepts, you can build one yourself easily in any language (lots of examples), but Assembly or C are the most idiomatic as they allow you to get to a much lower level.

Every forth system is different, but they share a lot of design fundamentals. There are almost too many to count.

If you're okay with closed source, 8th has a very nice free version if you just want to get a hang of writing forth code in it. I usually recommend that one check out 8th as it comes with all the niceties of modern scripting languages and can cross-compile to a lot of systems, has GUI support, bluetooth, iPhone/Android, modern data structures, database support...etc.

It's also a bit confusing that most Forth systems were traditionally for embedded work. There are a few commercial offerings (SwiftForth and VxForth) for that. It used to also be extremely common to bootstrap new hardware with Forth as you got a full REPL so you could interactively interact with the hardware and test out each piece before a compiler like C could be ported to the system. I'm not sure how common that is now, but there are a lot of Forth systems that are pretty barebones compared to modern languages. You have to look around.


Every forth system is different,

The joke is that if you have seen one Forth system, you have seen one Forth system :)


Probably the most straightforward thing to do is to learn and implement your own based on an early Forth like FIG Forth or Forth 83: http://www.forth.org/fig-forth/contents.html

http://forth.sourceforge.net/standard/fst83/

There are certain cosmological nuances of Forth that come through by the time you get to where you have bootstrapped IF ELSE - and while later Forths add more features(which is great for production uses) they aren't the essence of Forth, which is in the minimalism.

Factor is also so much different that it deserves another category, despite syntactic resemblance.


A few comments follow; note that I'm not unbiased :)

RetroForth is smaller and easier to build than gforth or Factor. I actively use it and seek to improve it, and I've been told the documentation is good, though I still feel I have a long way to go on that front. It's not a traditional Forth, but it works well for me. I borrow things from traditional Forth, colorForth, Factor, 8th, and other languages when I think they make sense for my needs. Releases are quarterly, with daily snapshots provided.

Gforth is big and I find it to be difficult to build from source. If you need or want a traditional/standard Forth, it's probably what I'd recommend if using one of the commercial ones isn't an option. Definitely build it from source though; the releases are infrequent and the development versions have a lot of bug fixes and improvements.

Factor is big, has lots of interesting stuff, but apart from stacks and colon decisions, really doesn't feel like Forth to me. It is under active development, but releases other than snapshots are very infrequent (last in 2018). Building from source isn't something I've done with this in years, and platform support is more limited (Linux, Windows, macOS, on x86 or x86-64). I've borrowed some ideas and terminology from Factor over the years and would consider it worth learning from.


I would describe retroforth as a traditional forth (i.e. on the traditional chuck moore forth path), and gforth as a standard (ansi standard) forth


Factor is higher level with built-in support for lambdas (called "quotations") and a garbage collector and a ready made library. If traditional Forths are like C than Factor is like C#. You'll still get many of the same concepts but without the low-level friction that'll hamper you making fun things.


I recommend studying a simple Forth implementation. rwmj wrote a tutorial/x86 implementation, now widely called Jonesforth:

Main x86 source to bootstrap minimal interpreter/compiler: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

Further Forth definitions: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

rwmj gave some background in comments on the HN story: https://news.ycombinator.com/item?id=10187248


I think Factor is too high level to give you an impression of Forth. A multitasking, stand-alone Forth, with an optimizing compiler and assembler is something an average programmer can reasonably implement for themselves. The whole thing will definitely fit in your head, as well as your L1 cache.


Besides the syntax, Factor is way closer to Smalltalk and Common Lisp than to Forth.


People interested in learning what Forth is all about could examine Chuck's cmForth. Both its metacompiler and the Novix chip (or RTX 2000, both versions may exist) are pretty interesting.


And for those interested in an FPGA version with similar features, check out the J1 and J1B (32 bit) CPUs by James Bowman.

Remarkable machines in 200(ish) lines of Verilog.



There's another page by crc that links to the latest snapshot, documentation and, IMO most importantly, a directory with retroforth examples:

http://forth.works/


http timeouts, but https and gopher both work for me:

https://forthworks.com/retro

gopher://forthworks.com/1/retro


The server limits the number of connections; this is likely the heaviest traffic it's seen; I've raised the limits a little to hopefully help with this.


So forthnoworksanymore. Lol.



If you’re into this you may also like durex forth: https://github.com/jkotlinski/durexforth

A modern C64 variant, as well as CollapseOS which is a Forth based 8-bit OS: https://collapseos.org/


Also see RainbowForth in the browser http://rainbowforth.appspot.com/


I think this is the offline version: http://rainbowforth.sourceforge.net/


Why would it need access to my Google account?


It shows my email in the upper right, so it is signed in to something apparently.


RainbowForth is interesting, but unrelated to RetroForth.


I am wondering why the site provides linux installation instructions only for a Turkish nationalist linux distribution: Milis Linux.

I haven't heard of this distribution before, but it seems it is focused on Turkish nationalists who ideolize a national operating system. The terminology they use seems also very right-wing to me.


That’s probably the only distribution that reached out to the RetroForth maintainers.


That is correct.

I use FreeBSD and OpenBSD, the ports/packages for others are contributed by others.


Why is the only documentation in epub format?


It's not only in ePub.

The canonical source for the documentation is in doc/book, with HTML formatted copies in doc/html and a Markdown copy as doc/RETRO-Book.md. The glossary of words is also included separately as a text file under the doc directory.


The current ePub isn't put together right, so it just has headings for the pages and no actual content. You can find the docs in the archive as Markdown files.


I've identified the issue. A correctly built copy of the ePub is at https://forthworks.com/retro/r/RETRO12-2021.1.epub (replacing the broken one) and I've now issued a 2021.2 release to fix the issue that caused this.


I'll investigate this and get a bug fix release out ASAP.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: