4 ms·

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 actu

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.

zzo38computer 9y ago
I happen to like MMIX, although I think is good they can make these free instruction set such as RISC-V and MMIX.
renox 9y ago
What makes you think both are related? AFAIK MMIX isn't a very "practical" ISA.
- monocasa 9y ago
  Yeah, it has something like 256 64bit GPRs. Not even the big monster CPUs have that many microarchitectual registers to rename to.
  - Veedrac 9y ago
    Well Haswell is 168 integer + 168 FP.
    - deleted 9y ago
      [deleted]
FullyFunctional 9y ago
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 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.
- MycroftJones 9y ago
  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?
  - FullyFunctional 9y ago
    (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.v 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 :)

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.

zzo38computer 9y ago

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

renox 9y ago

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

monocasa 9y ago
Yeah, it has something like 256 64bit GPRs. Not even the big monster CPUs have that many microarchitectual registers to rename to.
- Veedrac 9y ago
  Well Haswell is 168 integer + 168 FP.
  - deleted 9y ago
    [deleted]

FullyFunctional 9y ago

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 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.

MycroftJones 9y ago
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?
- FullyFunctional 9y ago
  (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.v 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 :)