On a Mill-based workstation, binary code stored in load modules is in an intermediate format that is common to all Mill family members. At load time, the loader checks to see if there’s a version of the binary code that is specialized to the particular Mill family member in the machine, and if so, loads that. If not, it creates one using the specializer library, and caches it in the load module.

That’s clear, but I’m wondering, how is this bootstrapped? Who specializes the specializer? And come to think of it, who specializes the BIOS? Can a single BIOS support multiple Mill family members, or would I need to re-flash the BIOS prior to upgrading to a different Mill CPU? What about the OS boot loader and kernel?

I can think of solutions to all of these, but will keep them to myself as per request. And anyway, I’d rather know how you plan to do it :).

Vendors and OEMs will no doubt use all the strategies you suggest, and others no one has though of. One we have considered for our own products is to use Multi-chip Module technology to put a ROM in the same package with the CPU, containing a pre-specialized in-memory specializer for all the (possibly different) cores in the package. The ROM would also contain the emulation code for operations not present in the hardware, and minimal initial code for things like trap and fault handlers and the power-up sequences, to give the BIOS a canonical platform to work on regardless of which family members are present.

The Mill approach to binary compatibility is not a panacea; we are still sensitive to the genForm distribution format, which must be stable and forward-compatible across the family, just a binary format must be stable and forward-compatible across other families such as the IBM mainframes. GenForm is not yet stable even for us; we are actively at work on it, but it will be done long before first product ships.