Reply To: Specification

Complex answer here, please bear with me.

Of the four reserved bits, one is not needed if the hardware is never going to support the Unix fork() function; any other thread- or process-spawning function will still work, but specifically not fork(). There will be a talk on how we do fork() sometime in the future; it’s non-trivial on a single-address-space machine.

The remaining three reserved bits are not needed if the hardware is never going to support garbage collection, or only support garbage collectors that cannot (or do not) use the hardware event-trap mechanism that uses those three bits.

Because few if any embedded systems need either fork() or garbage collection, the four reserved bits could be used for addresses on such a system.

For the remaining address space bits, the Mill is inherently a single-address-space machine, and while you could use the Belt and other Mill notions on a conventional multi-space architecture, the result would not be a Mill. Consequently, for a Mill the size of pointers is dictated by the size of the total shared address space that is required by the application. If all the memory used by all threads of all processes is less than 256 bytes you could in principle have a Mill with one-byte pointers, although other aspects of the architecture are way too heavy-duty to compete with the likes of Atmel. A 16-bit pointer is only somewhat more plausible, and I think that the Z80 market is safe from us.

However, embedded systems that currently run in 32-bit chips with no MMU should also be able to run in a Mill with 32-bit pointers and no native 8-byte arithmetic. However, the designers of such a chip would have to think hard about what else of the basic Mill to leave out: the PLB (losing wild-address protection and portal calls)? the TLB (losing backless memory, and paging of course)? Self-tuning transfer prediction, or prediction at all for that matter? All unclear, and heavily customer-driven.

So I guess the answer to your final question is: eventually possible and very low priority.