Difference between revisions of "Preliminary Design for Mill-Forth"
From Mill Computing Wiki
(Initial thoughts on the design of Mill-Forth) | |||
| Line 17: | Line 17: | ||
* Initially, MF will run on a simulated Mill CPU. | * 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. | + | * 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. |
---- | ---- | ||
Revision as of 17:38, 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.
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.
