Difference between revisions of "Forth for the Mill and/or Forth-like variants, better suited to the Mill"
From Mill Computing Wiki
m | m | ||
| Line 3: | Line 3: | ||
Why would one want an interpreter instead of the compiled languages (C, C++ and ??) that LLVM will support? | 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 and assembler are getting close to alpha/beta/possibly-usable-under-NDA status. | + | * Timing (Namely, I hate to wait!) The LLVM port won't be ready for some time, but the genAsm language [[http://millcomputing.com/wiki/GenAsm_(language)]] and assembler are getting close to alpha/beta/possibly-usable-under-NDA status. |
| − | * Simplicity. Some interpreters, especially threaded/stack-based interpreters like Forth (see [http://en.wikipedia.org/wiki/Forth_%28programming_language%29]) are | + | * Simplicity. Some interpreters, especially threaded/stack-based interpreters like Forth (see [http://en.wikipedia.org/wiki/Forth_%28programming_language%29]) 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. | * 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. | ||
Revision as of 17:37, 3 January 2015
An interpreter for the Mill would provide an another way to get software running on the Mill than 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 creating new keys. Here's the start of a short cartoon series on RPN [4]
