Difference between revisions of "Forth for the Mill and/or Forth-like variants, better suited to the Mill"
m | |||
| Line 1: | Line 1: | ||
| − | An interpreter | + | An interpretetd language and interpreter 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 [[http://millcomputing.com/topic/simulation/#post-1548]]. 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? | Why would one want an interpreter instead of the compiled languages (C, C++ and ??) that LLVM will support? | ||
| Line 29: | Line 29: | ||
---- | ---- | ||
| − | Please put links to Forth-like, but non-Forth languages here | + | '''Please put links to Forth-like, but non-Forth languages here.''' |
---- | ---- | ||
Revision as of 18:11, 3 January 2015
An interpretetd language and interpreter 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 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.
Please put links to Forth-like, but non-Forth languages here.
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.
Namespaces: The Forth implementations I've seen have a single, flat namespace. This is another issue for writing large Forth programs.
