Specification

Hi Ralph, thanks for the encouragement!

The specification video is being edited right now. There’s a lot of live demo so the video production takes some extra time but we’re pushing it along as fast as possible.

It will be posted to this forum and the mailing list as soon as its available.

The video and slides from the Specification talk will be on the site as soon as post-production is done; we hope this week.

Thanks again for another enjoyable presentation.

Am I correct in thinking that there is a deep relationship in the design of your simulator, and the “specializer” adaptive loader?

(this is pretty much a yes-or-no question; so don’t bother to spend too much time on an elaborate reply).

cheers, – vic

No deep relationship. The sim accepts specializer output (or manual asm).

After watching the specification talk, I got the impression that a key parameter of the Mill’s architecture, namely the bit-width of pointers (64, with 4 bits reserved) was not a free parameter, but is a “hardwired” part of the Arch. Are pointer width (and the number of reserved address bits) hardwired, or are those both parameters that I managed not to see in the specification?

64-bit wide pointers makes sense for general-purpose computing and for competing on the high end. However in the higher end of the embedded CPU world (e.g. 32-bit ARM and MIPS based chips), which has large and increasing volume, 64-bit wide pointers would hurt code density, especially for processors with all their memory on chip. Even with 4 bits of a pointer reserved, as in the Mill as shown in the presentations, 2^28 bytes of address space would dwarf the memory on such chips, and will for quite some time. (Right now, on-chip memories in such chips are typically a megabyte or less.) Is a 32-bit Mill completely out of the question, or is it eventually possible, but simply a very low priority?

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.

Ivan,

Thanks much for your detailed answer, and on a holiday no less! If I understand you correctly, having a single address space (of whatever width) is fundamental to being a Mill (versus being some other flavor of belt machine.) However, the number of bits required for a Mill’s address space is not intrinsically (and forever) 64 with four reserved.

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

Thank you; I will try to cultivate patience.

• This reply was modified 10 years, 7 months ago by  LarryP. Reason: clarity

Is C200x the proposed Unix time standard?