Difference between revisions of "Preliminary Design for Mill-Forth"
From Mill Computing Wiki
| Line 33: | Line 33: | ||
'''Key parts of MF:''' | '''Key parts of MF:''' | ||
| − | * A readable stream of characters for input. | + | * '''A readable stream of characters for input.''' |
| − | * A write-able stream of characters for output. | + | * '''A write-able stream of characters for output.''' |
| − | * | + | * '''A stack to hold data.''' |
In classic Forth, ALL data is passed between Forth words (essentially functions) via a stack that is separate from the return stack. | In classic Forth, ALL data is passed between Forth words (essentially functions) via a stack that is separate from the return stack. | ||
| − | * | + | * '''A return stack (or functional equivalent.)''' |
In classic Forth, a return stack -- separate from the data stack -- is used to record where to return to at the end of each Forth word. In normal usage, the only thing that goes onto this stack are addresses of Forth words (or something trivially convertable into such addresses.) | In classic Forth, a return stack -- separate from the data stack -- is used to record where to return to at the end of each Forth word. In normal usage, the only thing that goes onto this stack are addresses of Forth words (or something trivially convertable into such addresses.) | ||
| − | * Working Memory | + | * '''Working Memory''' |
Forth's memory management is extremely simple; the "dictionary" is a contiguous chunk of memory that Forth uses for both words and "global" variables. | Forth's memory management is extremely simple; the "dictionary" is a contiguous chunk of memory that Forth uses for both words and "global" variables. | ||
Revision as of 17:56, 4 January 2015
{Started 04Jan2014 by LarryP} Feel free to add and/or comment, but please don't wholesale remove content unilaterally.
Mill-Forth (MF) Design Context:
- The partial Mill tool-chain (specifically the genAsm assembler, the specializer and the simulator) are the tools I expect will be used for the initial effort. So the core of MF must initially be written in Mill genAsm.
- A simple design is more likely to work -- even if it doesn't do everything everybody wants. And working code is vastly more valuable than fragments of a more capable design that never quite runs.
- We can -- and probably should -- revisit MF's initial design after we have something working, but IMHO that should be a new phase of this project, assuming we get there.
Mill-Forth Design Assumptions:
- We must assume that our code can and will start running with permissions sufficient to read and write at least one specified range of memory. Otherwise, I can't see how MF can do anything useful. I assume we'll know the location and size of that region, that it'll be at least 64*1024 bytes, and that we should use proper Mill pointers for addresses.
- Initially, MF will run on a simulated Mill CPU.
- Since we likely won't have an O/S or even a BIOS, we will have to emulate I/O via either simulator outcalls or simple (ring?) buffers in memory. However, I think abstracting MF's input and output behavior will make MF more portable and useful. Note that Forth has been used in a number of non-X86 system designs (IBM Power servers, SUN workstations, PowerPC Macs) as part of their boot firmware. Google "Open Firmware" or OpenBoot for details.
- We will use ASCII-encoded bytes for input and output in the initial version. Other character sets (e.g. UTF-8, etc.) will have to wait or not happen.
Nice but not necessary (probably defer until phase 2+):
- Having a contiguous chunk of persistent memory would be nice, e.g. to save some state between MF invocations, but adding this will depend on the simulator's capabilities.
- A design that permits multiple MF interpreters to co-exist (e.g. with separate I/O streams, memory and permissions) and optionally with a means for them to "play nicely with one another" seems desirable.
Key parts of MF:
- A readable stream of characters for input.
- A write-able stream of characters for output.
- A stack to hold data.
In classic Forth, ALL data is passed between Forth words (essentially functions) via a stack that is separate from the return stack.
- A return stack (or functional equivalent.)
In classic Forth, a return stack -- separate from the data stack -- is used to record where to return to at the end of each Forth word. In normal usage, the only thing that goes onto this stack are addresses of Forth words (or something trivially convertable into such addresses.)
- Working Memory
Forth's memory management is extremely simple; the "dictionary" is a contiguous chunk of memory that Forth uses for both words and "global" variables.
How best to map the core components of Forth onto the Mill"
TBD
