eversl

If you manage to compile Qemu or Bochs or some other emulator you should be able to run a complete x86 operating system. It will cost you a great deal in terms of speed though, unless you go out of your way to produce heavily optimised mill code from the x86 instructions in a JIT-like fashion. That is essentially what Transmeta did with their Crusoe processors.
(And maybe that Soft Machines CPU as well)

From what I understand so far from the published materials the Mill seems designed well enough to not suffer from the same pitfalls that prevented the Transmeta chips from really performing as promised (Large VLIW instruction words, small 64MB translation cache, low memory bandwidth…). On top of that it would be possible to provide a ‘super speed mode’ that runs applications compiled to the native Mill instruction set right inside of an x86 (or x64) Linux or Windows.

Sounds like that would make for an appealing desktop or server product. Maybe such a system would benefit from some extra instructions on the Mill CPU that take care of some performance critical stuff (TLB lookups or fast x86 register restores come to mind).

Would you consider adding some instructions for this purpose?

We’ve been busy completing the sim and compiler toolchains. Making good progress but a lot to do still.

The Coremark results so far show that a Mill Gold will be able to perform on par (CoreMarks/MHz) with recent Intel and AMD CPUs. That is about as much as can be expected for Caremark, considering the nature of the benchmark and the level of focus it has been receiving from compiler writers already.

Essentially, Coremark is a small benchmark that can be run entrirely out of L1 cache, and all branches can be (almost) perfectly predicted given enough cache and predictor tables. For OoO CPUs it then becomes a matter of exploiting all instruction-level parallelism in the code, of which there is not a lot.

The Mill essentially can find the same instruction-level parallelism, and statically schedule it. The compiler toolchain (specializer) still leaves some opportunities for parallelisation unused, so there is some opportunity for improvement available, in the order of 10%.

We’re now moving on to (micro) benchmarks where the Mill will truly shine, which will be in areas like code with more instruction-level parallelism, amenable to auto-vectorisation, and a need for stricter security.

I agree that with web-apps running in javascript and wide use of java and other VMs legacy binaries are much less of an issue now. If Google or someone else decides to build a Mill-based chromebook or android device we would all be quite happy. And if x86 compatibility becomes an issue, it will be a matter of writing the code for it. It’s been done before…

But I take it from both of your reactions that x86 (or any other CPU) compatibility is not part of the plan for Mill CPUs (like the SoftMachines guys clearly do). If the power and speed numbers come out as planned I guess there’s plenty of opportunity for a Mill anyway.

Indeed, binary translation would be the way to get reasonable (or even good) speed while running a nonnative instruction set. Its just that there are probably lots of corner cases that would require complete emulation of the x86 cpu and system (precise exception semantics and probably the x86 memory addressing) at least some of the time.
Anyway, this has been done before on multiple CPU architectures, so there is probably also a way to do it with a mill CPU. It just made me think that the wholly admirable goal on which Transmeta was based — running x86 code on a simpler, low power CPU by doing all of the instruction decoding and scheduling in software — might be within reach as just one of the possible applications of a mill CPU. Running code compiled for mill will be even better, but that requires recompiling from source and might not work out of the box, at least initially, so having the option of x86 binary compatibility probably helps to make inroads in markets like desktop and server systems.

It’s not a trivial thing to build a fully compatible binary translator however, so I can imagine this is not yet on the radar for some time to come.