Reply To: Co-Exist and Merge: Not Supplant.

Co-exist? It’s not clear one would want to 🙂 Binary translation is pretty good these days, and the Mill makes a pretty good ISA interpreter. We expect to ship an x86 translator/interpreter with the Mill. We need it because some I/O devices we will want to support come with on-board x86 code.

Code aside, there’s a lot of levels of “co-existence” between any pair of architectures. For example, what do you do if the cores have different endianness and share address space?

Specific to the Mill, endianness aside the Mill is reasonably data-compatible with any modern architecture, although the reverse is not necessarily true. Pain points might include the Mill support for IEEE decimal floating point (unless the other core was an IBM z-series), and the Mill’s support for quad (16 byte) scalar in both integer and floating point. However, if the app doesn’t use those types then alien cores should work OK when exchanging data with a Mill. Going the other way, the Mill won’t support 36-, 48-, and 80-bit data types as seen in various antiquated architectures, at least without software conversion.

If there is any problem, it will be in the memory hierarchy and the protection model when a Mill and another core are on the same chip and share address space. The Mill separates protection from paging and protects at byte granularity. Consequently it would not be possible for a Mill and an ARM (say) to safely share a 17-byte buffer, while two Mills can do so. The Mill also supports backless memory that has no allocated pages, which is impossible on a core where paging is in front of the caches. Consequently any memory shared between Mill and non-Mill would have to have real DRAM allocated for it. All these issues can be handled in software, but would have to be addressed.

Cache coherency issues cannot be handled in software for performance reasons, and the Mill coherency protocol is vastly simpler than and incompatible with the usual MOESI. Mill coherence is NYF, but I think hardware could force the Mill to use MOESI, although the performance hit would be painful; we’d be as slow as an x86.

A similarly painful hardware problem might occur with concurrency control. The Mill uses optimistic concurrency control, and should have no problem working with cores that also do so: PowerPC, M68k, z-series. However, cores that use bus locking for concurrency might have trouble. At a guess, you’d probably have assertion of a bus lock cause a bust of any in-flight Mill transaction. Going the other way, I suppose you could have the bus locked for the duration of an active transaction. Both of these would have a lot of spurious interference; it that was enough of a problem then you’d need more hardware smarts to do the integration.

Now your question addressed several chips on a board whereas my reply mostly addresses several cores on a chip. At the board level the only problem is data compatibility, which endianness aside should not be a problem. The Mill doesn’t share address space off chip, so all the hierarchy and protection issues are obviated.

Reading between the lines of your posting, it seems as if you expect that only solution to co-existence is to put an actual ARM or x86 core on a Mill chip. That may have once been true, but is no longer. Software translation is within a factor of two of native these days, and with a factor of ten to play with I doubt that we would ever put an alien native core on a Mill chip. Of course, a motivated customer could change my mind 🙂