
MMIX 2009: A RISC computer for the third millennium (2011) - tambourine_man
http://www-cs-faculty.stanford.edu/~knuth/mmix.html
======
plinkplonk
" The original MIX computer ran fine without an operating system. You could
bootstrap it with punched cards or paper tape and do everything yourself. But
nowadays such power is no longer in the hands of ordinary users. The MMIX
hardware, like all other computing machines made today, relies on an operating
system to get jobs started in their own address spaces and to provide I/O
capabilities.

Whenever anybody has asked if I will be writing a book about operating
systems, my reply has always been ``Nix.'' Therefore the name of MMIX's
operating system, NNIX, should come as no surprise.

From time to time I will necessarily have to refer to things that NNIX does
for its users, but I have no intention of building NNIX myself. Life is too
short. It would be wonderful if some expert in operating system design became
inspired to write a book that explains exactly how to construct a nice, clean
NNIX kernel for an MMIX chip. The MMIX fascicle includes a level-50 exercise
that asks a highly motivated reader to ``Write a book about operating systems,
which includes a complete design of an NNIX kernel for the MMIX
architecture.'' Other alternatives are also possible; for example, somebody at
the Free Software Foundation might decide to come up with an alternative
system called GNNIX. "

~~~
masklinn
> " The original MIX computer ran fine without an operating system. You could
> bootstrap it with punched cards or paper tape and do everything yourself.
> But nowadays such power is no longer in the hands of ordinary users. The
> MMIX hardware, like all other computing machines made today, relies on an
> operating system to get jobs started in their own address spaces and to
> provide I/O capabilities.

Unikernels come back to that, to an extent, what there is of the OS is part of
the application, and IO capabilities are provided by libraries linked into the
unikernel application. As always, the issue is having IO drivers for the
hardware in a form which can be used.

------
andrewbinstock
If you're interested in designing a RISC processor in software, Knuth's full
book on MMIX is an interesting and complete read. I am not referring to the
short version published as part of Volume 1 the revised TAOCP, but the full
exposition in his book from Springer-Verlang. [1]

There he explains the CPU, the memory management, the instruction pipeline.
And he builds the assembler for the machine. He worked with David Patterson
(of MIPS fame) on the architecture.

As to the implementation, Knuth once commented that the coding of the
instruction pipeline for MMIX was the hardest programming he'd ever done.

Cool stuff!

[1]
[http://www.springer.com/gb/book/9783540669388](http://www.springer.com/gb/book/9783540669388)

------
faragon
The 2009 figure is not the year, but a result (the PDF [1] has the Copyright
set in 1999)

(Cray I + IBM 801 + RISC II + Clipper C300 + AMD 29K + Motorola 88K + IBM 601
+ Intel i960 + Alpha 21164 + POWER 2 + MIPS R4000 + Hitahi SuperH4 + StrongARM
110 + Sparc 64) / 14 = 28126 / 14 = 2009

[1]
[http://mmix.cs.hm.edu/doc/fasc1.pdf#page=7&zoom=auto,-250,56...](http://mmix.cs.hm.edu/doc/fasc1.pdf#page=7&zoom=auto,-250,562)

~~~
Jabbles
Read the next sentence :)

~~~
technomalogical
TIL deep linking URL syntax for PDFs in Chrome, thanks!

~~~
faragon
"The same number may also be obtained in a simpler way by taking Roman
numerals."

------
unwind
The names of the machine's primitive data types are interesting, and
refreshing if you're tired of the more well-known ones. These are the load
instructions, for reading data from memory:

    
    
        Load a Byte           LDB $X,$Y,$Z
        Load a Wyde (2Byte)   LDW $X,$Y,$Z
        Load a Tetra (4Byte)  LDT $X,$Y,$Z
        Load an Octa (8Byte)  LDO $X,$Y,$Z
    

I thought the "wyde" in the instruction set reference was a typo, until I saw
that it was used all over the place. :)

I guess it's better (less ambiguous) than "word", "long", "double word", and
so on.

~~~
cjdrake
"Two bytes makes one wyde."

Can't remember where I heard/read that, but it's classic Knuth humor :).

------
kazinator
See:

    
    
       SYNC   SWYM
    

in last opcode row. :)

~~~
wolfgke
And

    
    
       GET TRIP
    

next. :-)

------
du_bing
I find Knuth's idea fascinating. The fashionable languages come and go, but
facts about how machine works does not change much, probably will not in the
future.

~~~
userbinator
I would disagree: just compare MIX with MMIX.

MIX is a 6-bit/2-digit hybrid binary/decimal sign-magnitude machine, typical
of 50s-60s machines. MMIX is a 64-bit binary big-endian RISC with 256 windowed
registers that resembles a hybrid of SPARC and MIPS, with all the traits of
that 90s "RISC dream" that never really went anywhere.

If he were to design it today, it would probably look more like a mix of x86
and ARM.

~~~
masklinn
> If he were to design it today, it would probably look more like a mix of x86
> and ARM.

Why bother basing a _new architecture_ on x86 when it's generally considered
the worst ISA in history (with some boosting TI's TMS9900 instead)?

x86's advantage is basically its continuous dominance and compatibility with
itself which managed to thwart even its original designer's attempt to
displace it[0], but you won't get that by basing a new incompatible ISA upon
it, so there's really no point in doing so.

[0] Linus made that point reasonably clearly in a 2016 PCWorld interview:
[http://www.pcworld.com/article/3129300/linux/why-linux-
pione...](http://www.pcworld.com/article/3129300/linux/why-linux-pioneer-
linus-torvalds-prefers-x86-over-arm.html)

> What matters is all the infrastructure around the instruction set, and x86
> has all that infrastructure... at a lot of different levels

> I’ve been personally pretty disappointed with ARM as a hardware platform,
> not as an instruction set […] As a hardware platform, it is still not very
> pleasant to deal with.

And this is a lesson he learned: while originally interested in the Acorn
Archimedes (which wasn't a great success) he went with the Sinclair QL (which
outright failed) and…

> Finland wasn’t the center of the universe back then, after that, I learned
> my lesson: never ever go buy into something that doesn’t have
> infrastructure.

~~~
CalChris
If I were designing something today, something clean, I'd give a really good
look at just cleaning up x86_64. AMD64 did some of that.

What is RISC-V but a cleaned up RISC, omitting the architectural mistakes of
previous RISCs (branch delay slot (MIPS), register windows (RISC-1), tagged
integers (SPARC), ...). It has a place.

A cleaned up x86 would definitely have a place. The idea of parsing a CISC
instruction and translating+caching the result as a micro-op has worked, flat
out worked. Worst ISA in history? I think not. Most successful ISA in history.

Still, Intel really needs to do what ARM has done. Clean up their act. Itanium
was _changing_ their act. It kinda reminds me of the scene in _Spinal Tap_
where they introduced the _new direction_. Intel just needs to get rid of
their cruft, seriously needs to get rid of their cruft because ARM is a threat
and ARMv8 is a weapon. The x86 tax helps prevent competitors in their space
(as per their threats to Microsoft) but ARM isn't in their space; they're next
door.

------
lallysingh
So is there any work on making an FPGA implementation of this?

------
Koshkin
How do RISC architecture designers deal with the problem of low code density
when modern chip technology makes RAM access considerably slower than anything
that happens inside the CPU? One answer could be to have a huge instruction
cache, but I doubt that it is economically possible.

~~~
0xcde4c3db
As far as I know, the two major approaches are

1) Caches

2) Supporting a "compressed" variant of the instruction set (ARM Thumb,
MIPS16, RISC-V Compressed). This can be put together by using the same field
for target and destination registers, shrinking the set of named registers,
making shifts and conditions into explicit instructions instead of fields (for
ARM), and similar tweaks.

------
hvidgaard
Anyone know the status of vol 4 and "ultimate edition" of vol 1-3?

~~~
mci
Vol 4A was published in 2011: [https://www.amazon.com/Art-Computer-
Programming-Combinatoria...](https://www.amazon.com/Art-Computer-Programming-
Combinatorial-Algorithms/dp/0201038048/)

Vol 4B was partially published in fascicles: [https://www.amazon.com/Art-
Computer-Programming-Fascicle-Pre...](https://www.amazon.com/Art-Computer-
Programming-Fascicle-Preliminaries/dp/0134671791/) and
[https://www.amazon.com/Art-Computer-Programming-Fascicle-
Sat...](https://www.amazon.com/Art-Computer-Programming-Fascicle-
Satisfiability/dp/0134397606/)

Instead of the ultimate edition of vols 1-3, so far we've got a "patch" by
Martin Ruckert who coordinated the volunteers: [https://www.amazon.com/MMIX-
Supplement-Computer-Programming-...](https://www.amazon.com/MMIX-Supplement-
Computer-Programming-Volumes/dp/0133992314/)

~~~
hvidgaard
Thanks for the pointers.

This
[https://cs.stanford.edu/~uno/taocp.html](https://cs.stanford.edu/~uno/taocp.html)
seems up to date.

------
kruhft
I've always wanted to implement the MMIX processor using this:

[http://github.com/burtonsamograd/anser](http://github.com/burtonsamograd/anser)

------
harry8
The issue i have with Sedgwick, cormen et al is they ignore hardware. Is Knuth
really better?

How is the cache heirachy different in MMIX as compared MIX?

~~~
Jtsummers
What hardware should they base their book on? Would it be universally
applicable? Should they drop down to assembly level (as Knuth has) or stick to
some higher level language?

Their choice of using a pseudocode allows the algorithms they discuss to be
accurately and completely specified, while leaving the implementations up to
specific platform (hardware and language) developers and users.

------
pubby
MMIX was such a stupid idea by an otherwise genius person. So much effort and
knowledge was put into TAOCP and yet it's wasted on the vast amount of people
who aren't interested in learning a fantasy assembly language.

I can't really fault Knuth for the original MIX. I mean, it _was_ written in
the 1960s; a time when programming languages barely existed. But by 2009 it
should be clear to everyone that C derivatives are here to stay, and that
assembly programmers are dying off. Creating yet _another_ fantasy assembly
language in the year 2009 was just stubborn and dumb.

~~~
ianai
That's like, just your opinion, man. There's always going to be that lowest
level before 1s and 0s. (I say this as I'm curious if this assumption of mine
is actually out of date at this point.)

~~~
AstralStorm
Not really, and the hardware is getting more complex all the time. A modern
CPU is like a probabilistic OS nowadays...

