Hacker News Reader

Comment by MycroftJones | Hacker News Reader

So, how does RISC-V compare with Donald Knuth's MMIX instruction set? Did they use it as a starting base? Consider it at all? Be cool to program MMIX in actual hardware.

View on HN

What makes you think both are related? AFAIK MMIX isn't a very "practical" ISA.

Yeah, it has something like 256 64bit GPRs. Not even the big monster CPUs have that many microarchitectual registers to rename to.

Well Haswell is 168 integer + 168 FP.

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?

(EDIT: typos galore)

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 :)

I happen to like MMIX, although I think is good they can make these free instruction set such as RISC-V and MMIX.

Reply on news.ycombinator.com