If you consider an FPGA board real hardware, then yes, I've run MMIX programs, including graphics, on real hardware: https://github.com/tommythorn/fpgammix Caveats: this is some of the worst Verilog I've even written; I was explicitly racing ahead learning about MMIX as I went along. In the end I had a large subset (integer usermode) when I abandoned it. As much as I wanted to like it, it's really a pretty terrible architecture from most perspectives: it's impossible to scale down, hard to scale up, and nearly impossible to generate good code for. In contrast, RISC-V is IMO the nicest RISC ISA ever design.
Cool! Thanks for the hard work, and the insight. For those of us that don't speak Verilog, do you have a paper or some other writeup of the things that make MMIX less than ideal? Other than the scaling up/scaling down. Does that primarily consist of the 256 registers? Neither more or less?
Thank you. Boy, this was a long time ago and I haven't written anything. I suspect it will be obvious for anyone skilled in the act, but I had to go look at my code at bit to remember some of this.
First a quick word from the POV of a compiler: the register windows are supposed to make function call easier and I suppose it works as designed for hand written code, but it actually adds a lot of complexity to indirect call/virtual functions and is a disaster for anything that switches stack (context switches, coroutines, etc). Another problem is the immediate fields which are just 8-bit unsigned, very often too small. And in practical terms, the GCC port really struggles to make good code for MMIX. Try it!
From the implementation POV: even ignoring the resource requirement for the full MMIX (which besides 256 registers includes a LOT of functionality), it's hard to pipeline as MMIX actually have fairly complicated semantics; just look at the state machine, the S_XXX symbols in https://github.com/tommythorn/fpgammix/blob/master/rtl/core....
While you can obviously deal with that (as witnessed by x86), it requires you to speculate a lot (for starters, speculate that you didn't get an interrupt). All speculation add complication as you need to recover from mis-speculation. This in term hurts cycle time by making stages more complicated and is a MAJOR source of verification work (AKA bugs).
My implementation is nearly completely un-pipelined, very similar to a simple interpreter but in Verilog. Once I had enough functionality that I could look back and consider a more realistic implementation, I really lost the enthusiasm and instead focused on MIPS which is dramatically more efficient and easier to implement (pesky branch delay-slot not withstanding). Of course, later a friend leaked word of nascent RISC-V and the world was forever different.
I actually asked Don directly why he hadn't gone with something like MIPS, but he answered vaguely that he wanted something for education.
On the positive side, I found a bug and scored a $2.56 check (real dollars) and a couple of MMIX T-shirts :)
