Difference between revisions of "Forth for the Mill and/or Forth-like variants, better suited to the Mill"

Revision as of 16:52, 4 January 2015

An interpretetd language and interpreter would provide an another way to get software running on the Mill (versus the LLVM compiler port that is in process, but not yet ready as of this writing, 03Jan2015.) This idea was first proposed in the forums [[1]]. Mill architect Ivan Godard has expressed some interest (in the forum discussion linked above), but keep in mind that this is not an official Millcomputing effort.

Why would one want an interpreter instead of the compiled languages (C, C++ and ??) that LLVM will support?

• Timing (Namely, I hate to wait!) The LLVM port won't be ready for some time, but the genAsm language [[2]] and assembler are getting close to alpha/beta/possibly-usable-under-NDA status.

• Simplicity. Some interpreters, especially threaded/stack-based interpreters like Forth (see [3]) are simple enough to be feasible assembly-language projects. So an interpreter could be written for the Mill using either Mill concrete assembler or Mill genAsm. Ivan strongly recommends genAsm over conAsm.

• Size. An interpreter can run in a small (think kilobytes) amount of memory, and is thus likely to run on Mill simulator well enough to be usable, instead of frustrating.

• Hands-on Mill experience. Although watching the presentations and reading the discussions is interesting, I think there's no substitute for programming itself. I see this project as a means to learn more about the Mill CPU and the associated infrastructure and toolchain.

What is Forth? I'd describe it like so:

Picture an H-P/RPN calculator (one with an enter key, instead of an equals key) that has keys for doing most things you'd ike to do -- including adding new keys! Here's the start of a short cartoon series on RPN [4] that may give you a feel for it. (Imagine a programming language that works the way Yoda talks.)

Contributors, feel free to identify yourselves here.

LarryP (also reachable at ursine at G00gle's free email service)

Please put links about Forth, per se here.

A Beginner's Guide to Forth by J.V. Noble [5] is IMHO a good place to start, because it gives both a Forth tutorial as well as an overview of how Forth is structured and works.

The GNU Project's Gforth: [6]

Updating the Forth Virtual Machine by Stephen Pelc outlines the classic Forth VM and proposes an alternative VM: [7]

{LarryP, 03Jan2015} My current thoughts on how to proceed: I think the best initial strategy is to design a minimal version of Forth, assuming that we'll soon be able to use parts of Millcomputing's tool-chain (genAsm, specializer and simulator) for development, test and demonstration. It sounds like an NDA will probably be required for early access to the partial tool-chain.

Even a fairly basic (if you'll pardon a pun on another well-known interpreter), minimally-functional Forth interpreter, running on a simulated Mill CPU, would be no small feat. A successful port might well be the largest scale test of the partial Mill toolchain and simulator(s) until either the LLVM compiler port can generate Mill code or Millcomputing develops something bigger and better (and hopefully discloses it!)

Once we have a working Forth implementation, we could go a number of ways:

• Port the rest of standard/ANSI Forth, implementing the rest in our minimal Forth.

• Experiment with interpreter designs, to see what's the most efficient way to make Forth run on the Mill.

• Make more informed decisions on what features and characteristics ought to go into a Mill-optimized interpreted language.

Preliminary Design for Mill-Forth

Please put links to Forth-like, but non-Forth languages here.

FIRST & THIRD almost FORTH (author regrettably unknown) [8] This is a minimal and portable design, and the included source is impressively short.

Please discuss non-Forth-ish ideas (extensions/variants) here (or create and link sub-pages instead.)

Type safety/type versatility: One issue with Forth is that one cannot tell the intended type of operands on the Forth stack, simply by examining them. So, the user/programmer has to keep track of the intended types of what's on the stack. This makes it harder to debug and much harder for would-be-collaborators to work together efficiently. A related issue is "size tyranny." In the Forths I've seen, all operands on the data stack must be of the same size -- and that size must be large enough to hold an address on the target machine. IMHO, on the Mill, we'd like to be able to work with operands of all the types and sizes that the Mill supports.

Memory Management beyond Forth's linear, non-garbage-collected dictionary: Except for the data stack, all Forth memory allocation is via Forth's dictionary, one big, contiguous buffer with no garbage collection. Code (executable words) and user variables all co-exist in Forth's dictionary, without anything to distinguish which is which except program context.

Namespaces: The Forth implementations I've seen have a single, flat namespace. This is another issue for writing large Forth programs.