The center for all current news about MMIX has moved to Germany! I've "passed the baton" to a new generation of talented software wizards, and MMIX's future is now in their capable hands. See the MMIX home pages for further information.
MMIX is a RISC machine that has been gaining many aficionados because it is used in Volume 4A of The Art of Computer Programming and it will eventually be used in all other volumes of that series. (Click here for basic info about MMIX; click here for news about the book MMIXware.) Most of the early developments took place in 1999; click here if you're interested in such historical stuff. Most interesting, perhaps, are three videos of lectures given during that year:
- Two lectures available from Stanford,
- the first one introductory (09 February 1999) and the second with a cool prototype-demo of some pipeline-visualization software (03 March 1999);
- A lecture available from Dr Dobbs TechNetCast,
- given to the Boston ACM Chapter on 15 December 1999.
Here are the final drafts of the full story about the MMIX architecture and its assembly language and loader format, as well as a description of a rudimentary operating system and runtime environment that will be assumed in the simpler parts of my books.Definition of architecture details (143KB of compressed PostScript) (final version, 31 August 2011)
People have been accumulating several years of experience with a straightforward MMIX assembler and simulator, and I know that both programs work reasonably well on three platforms. The pipeline meta-simulator is also up and running, but with a user interface that is not for beginners. (This is one of the most difficult programs I've ever written, and surely one of the most interesting, for people who have time to explore low-level details.)Click here to download MMIXware: the simple simulator, assembler, test programs, and full documentation, plus the meta-simulator: mmix-20110831.tar.gz (Version of 31 Aug 2011)
In general these programs are now entirely stable: I won't be changing them any more, because they've proved their value in extensive use. Further developments, including versions that I myself do not maintain, are however ongoing. All the really current news about MMIX is, in fact, now to be found in the MMIX home pages.
All the software and documentation have also been printed in a handy book format, with mini-indexes on each right-hand page so that you can easily find your way around. I also prepared a comprehensive master index to all the programs. Everybody seriously interested in MMIX will enjoy this book, available from Springer Verlag as Lecture Notes in Computer Science number 1750.
See also the
Windows-oriented MMIX simulator including a Video RAM prepared by Professor Axel Böttcher,
as well as the Un*x/X11-based MMIX simulator by Andrew Pochinsky of MIT's Center for Theoretical Physics.
And there's now a C/C++ compiler too! On 31 December 2001, Hans-Peter Nilsson told me that his GCC port for MMIX is now part of the "official" GNU sources. Here are his installation instructions.
Furthermore Evgeny Eremin of Perm State Pedagogical University has a rapidly growing set of freely available MMIX-based tools including a simulator, I/O ROM, Java applets, and a compiler from Pascal to MMIX.
See also Peter Nikouline's MMIXAL.NET project.
All of the MIX programs in Volumes 1--3 will need to be rewritten in MMIX, before I finish the ``ultimate'' edition of those volumes that I plan to write after Volume 5 is completed. The current target date for the ultimate volumes is the year 2020, so there is plenty of time to do the conversion. But I think it will be an instructive undertaking if different groups of people from around the world try to do the necessary translations first, perhaps in friendly competitions, long before I get into the act.
If you're interested in joining this happy group of volunteers, take a peek at the MMIXmasters home page, and/or the MMIX home pages.
Besides the MMIXmasters site just mentioned, other communities of MMIX users are beginning to set up related webpages. I will list them here as soon as I learn about them. The first is a German MMIX site at the University of Applied Sciences in Munich. The second is Eremin's Russian/English site mentioned above.
Everything in MMIX is designed to work well when Unicode becomes more widely used, but the present simulators are still ASCII-based. For some time I've been asking people about the best way to extend the traditional UNIX conventions about command-line arguments (which are strings of 8-bit characters) to allow command-line arguments in Unicode. I guess the current consensus is that Unicode command-line arguments are to be written in the so-called UTF8 encoding. But I would much prefer a system in which pure 16-bit characters could be used by people who prefer to work entirely that way, and where the same machine-language binaries would work with either convention.
The best solution I have come up with so far is to have an optional second entrance to each machine language program, called MainW, defined whenever the program is designed to work with 16-bit command-line arguments. The operating system knows whether a user is entering commands from an ASCII terminal or a UTF16 terminal. In the former case, it makes byte-oriented strings for the command line as usual and transfers to Main. In the latter case, it makes wyde-oriented strings and transfers to MainW, unless no symbol MainW has been defined. Finally, if MainW doesn't exist, Unicode characters are converted to UTF8 (with appropriate error/warning messages) and Main gets the action as usual.
Unless somebody comes up with a better scheme, I propose that future implementors of Unicode-based emulators of MMIX adopt this dual-entrance idea.
I know that Unicode has a special convention under which strings with characters of unknown width begin with the two 8-bit characters #fe and #ff, meaning "16-bit characters follow". (See The Unicode Standard 3.0, section 13.6.) This rule, however, does not allow backward compatability. And I couldn't live with it in The Art of Computer Programming, because it would make all assembly language programs inherently messy and complicated, really terrible from an educator's standpoint. My proposal does not conflict with such a convention; it simply extends it to allow another way to get the functionality without simultaneously losing the simplicity of the old way. (And I'm also interested in the majority of applications where the full generality of Unicode's non-plane-0 characters isn't needed.)