fas_ci_cle /fas_ ek el / n . 1: a small bundle . an inflorescence consisting of a compacted cyme less capitate than a glomerule. 2: one of the divisions of a book published in parts --P. B. Gove, Webster''s Third New International Dictionary (1961) This is the first of a series of updates that I plan to make available at regular intervals as I continue working toward the ultimate editions of The Art of Computer Programming. I was inspired to prepare fascicles like this by the example of Charles Dickens, who issued his novels in serial form; he published a dozen installments of Oliver Twist before having any idea what would become of Bill Sikes! I was thinking also of James Murray, who began to publish 350-page portions of the Oxford English Dictionary in 1884, finishing the letter B in 1888 and the letter C in 1895. (Murray died in 1915 while working on the letter T; my task is, fortunately, much simpler than his.

) Unlike Dickens and Murray, I have computers to help me edit the material, so that I can easily make changes before putting everything together in its final form. Although I''m trying my best to write comprehensive accounts that need no further revision, I know that every page brings me hundreds of opportunities to make mistakes and to miss important ideas. My files are bursting with notes about beautiful algorithms that have been discovered, but computer science has grown to the point where I cannot hope to be an authority on all the material I wish to cover. Therefore I need extensive feedback from readers before I can finalize the official volumes. In other words, I think these fascicles will contain a lot of Good Stuff, and I''m excited about the opportunity to present everything I write to whoever wants to read it, but I also expect that beta-testers like you can help me make it Way Better. As usual, I will gratefully pay a reward of $2.56 to the first person who reports anything that is technically, historically, typographically, or politically incorrect. Charles Dickens usually published his work once a month, sometimes once a week; James Murray tended to finish a 350-page installment about once every 18 months.

My goal, God willing, is to produce two 128-page fascicles per year.Most of the fascicles will represent new material destined for Volumes 4 and higher; but sometimes I will be presenting amendments to one or more of the earlier volumes. For example, Volume 4 will need to refer to topics that belong in Volume 3, but weren''t invented when Volume 3 first came out. With luck, the entire work will make sense eventually. Fascicle Number One is about MMIX, the long-promised replacement for MIX. Thirty-seven years have passed since the MIX computer was designed, and computer architecture has been converging during those years towards a rather different style of machine. Therefore I decided in 1990 to replace MIX with a new computer that would contain even less saturated fat than its predecessor. Exercise 1.

3.1-25 in the first three editions of Volume 1 spoke of an extended MIX called MixMaster, which was upward compatible with the old version. But MixMaster itself has long been hopelessly obsolete. It allowed for several gigabytes of memory, but one couldn''t even use it with ASCII code to print lowercase letters. And ouch, its standard conventions for calling subroutines were irrevocably based on self-modifying instructions! Decimal arithmetic and self-modifying code were popular in 1962, but they sure have disappeared quickly as machines have gotten bigger and faster. Fortunately the modern RISC architecture has a very appealing structure, so I''ve had a chance to design a new computer that is not only up to date but also fun. Many readers are no doubt thinking, "Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days." Such people are entitled to their opinions, and they need not bother reading the machine-language parts of my books.

But the reasons for machine language that I gave in the preface to Volume 1, written in the early 1960s, remain valid today: One of the principal goals of my books is to show how high-level constructions are actually implemented in machines, not simply to show how they are applied. I explain coroutine linkage, tree structures, random number generation, high-precision arithmetic, radix conversion, packing of data, combinatorial searching, recursion, etc., from the ground up. The programs needed in my books are generally so short that their main points can be grasped easily. People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. Machine language is necessary in any case, as output of some of the software that I describe. Expressing basic methods like algorithms for sorting and searching in machine language makes it possible to carry out meaningful studies of the effects of cache and RAM size and other hardware characteristics (memory speed, pipelining, multiple issue, lookaside buffers, the size of cache blocks, etc.

) when comparing different schemes. Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur . I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren''t the point of my books, the point is rather what you can do in your favorite language. My books focus on timeless truths. Therefore I will continue to use English as the high-level language in The Art of Computer Programming , and I shall continue to use a low-level language to indicate how machines actually compute. Readers who only want to see algorithms that are already packaged in a plug-in way, using a trendy language, should buy other people''s books. The good news is that programming for MMIX is pleasant and simple.

This fascicle presents 1) a programmer''s introduction to the machine (replacing Section 1.3.1 of the third edition of Volume 1); 2) the MMIX assembly language (replacing Section 1.3.2); 3) new material on subroutines, coroutines, and interpretive routines (replacing Sections 1.4.1, 1.4.

2, and 1.4.3). Of course, MIX appears in many places throughout the existing editions of Volumes 1--3, and dozens of programs need to be rewritten for MMIX before the next editions of those volumes are ready. Readers who would like to help with this conversion process are encouraged to join the MMIXmasters, a happy group of volunteers based at mmixmasters.sourceforge.net. The fourth edition of Volume 1 will not be ready until after Volumes 4 and 5 have been completed; therefore two quite different versions of Sections 1.

3.1, 1.3.2, 1.4.1, 1.4.2, and 1.

4.3 will coexist for several years. In order to avoid potential confusion, I''ve temporarily assigned "prime numbers" 1.3.1'', 1.3.2'',1.4.

1'', 1.4.2'', and 1.4.3'' to the new material. I am extremely grateful to all the people who helped me with the design of MMIX. In particular, John Hennessy and Richard L. Sites deserve special thanks for their active participation and substantial contributions.

Thanks also to Vladimir Ivanovic for volunteering to be the MMIX grandmaster/webmaster. D. E. K. Stanford, California May 1999.