I don't hate using assembly language, since I have written some in my os course. But obviously, assembly language lacks abstraction, you have to pay more attention to the details.

Is assembly language really essential to write TAOCP?

  • 6
    The details are where the devil is.
    – Blrfl
    Commented Apr 26, 2013 at 13:55
  • 5
    @Blrfl I don't believe in the devil. (I believe in the details though... shiver) Commented Apr 26, 2013 at 15:24
  • 3
    The first volume of TAOCP was published in 1968. Although higher level languages certainly existed, hand-written assembler was much more important then, and computing resources on mainframes back then could be of the same order as some 1980s 8-bit micros. Knuth also once argued quite seriously for keeping goto because some algorithms couldn't be written using nested control flow structures without some inefficiency. He actually didn't advocate premature optimisation even then IIRC, he just wanted the option available for when the optimisation was needed.
    – user8709
    Commented Apr 26, 2013 at 16:04
  • 3
    @JimmyHoffa: Oh, well, in your case, the details are where the de Ville is.
    – Blrfl
    Commented Apr 26, 2013 at 16:12
  • 1
    Jerry Coffin succeeded in doing what I wanted to do, he looked it up in the source ;-). I looked in the chapters where MIX and MIXAL are introduced, where I did not find such statements...maybe I should get an electronic copy some day. Anyway, I think the answer tag would be more appropriate for Jerry's reply in this case.
    – Thomas
    Commented Apr 26, 2013 at 16:33

4 Answers 4


He not only uses MIXAL, his assembly language for MIX, but also MIX, a model for a simple computer (like one which was used in the sixties). This is a model for teaching with which he is, to some extent, independent of development in the field.

If he'd used another programming language (which one, by the way, would you think would have been suited?), say NPL (nifty programming language), he would have had to either abandon the idea of using MIX or to introduce a compiler of some computer language of choice (which is a far more complex thing than what he is dealing with in Vol 1). That way it would not have become TAOCP but TAONPLP. The first one is independent of such a choice and, for this reason, timeless in a way few books about programming will ever be. The second one would probably be forgotten by now...

Also, as long as computers are working in principle the way his MIX does, it is a good thing to take that into account if you are really interested in learning how to work with them.

  • Note that "Compiler techniques" is officially the topic of the projected volume 7. It might still happen, but I think everybody is glad that Knuth didn't wait until he had a compiler to start publishing. Commented Apr 26, 2013 at 14:08
  • @KilianFoth yes I know. But I'd expect artificial programming languages to be used in such a book. Probably targetting an MMIX (the second M is not a typo :-) based computer. And ETA of vol. 5 is 2020....
    – Thomas
    Commented Apr 26, 2013 at 14:13

You young whippersnappers amaze me sometimes. You all too often have no clue that anything happened before you started school. (I have the same problem. It took me a long time to grasp that 15 years was actually a very short time, from an adult viewpoint. That's roughly the span from Hiroshima to the Cuban Missile Crisis. To me, World War II is just history, but my father fought in it, and my mother was in junior high during it.)

TAOCP, vol. 1, "Fundamental Algorithms", 1st edition, was first printed in 1968. That's 45 years ago. Knuth started planning the series well before then.

For reference: The Intel 8086 first appeared in 1978, ten years later. The PASCAL language first appeared in 1971; the Jensen & Wirth book, about the second version of the language, came out in 1974. Initial development of C was 1969-1973: K&R was published in 1978.

Knuth intended the series to cover the field. He set the style, THEN, to be useful to practitioners THEN. He did not ever expect that series to become quite literally his life's work, or its writing to span what will probably be well over half a century when he finally finishes.

Assembly language is arguably not as critical today as it was then, but it is still far more important than the Java/C++/Javascript/Python/Perl mavens would like you all to believe.


  • Knuth implemented an ALGOL compiler in 1960, and ALGOL was intended to be suitable for publishing algorithms, so I don't think this really answers the question. Commented Apr 26, 2013 at 14:18
  • 10
    I'm really not convinced the reasoning was availability of the time. LISP was available if he wanted it to have high level of abstraction like math does. I think he went with assembly because of the first word of the title; Fundamental. Nothing is more fundamental to algorithms than the step by step instructions to a simple stupid machine; it forces you to break the algorithm down completely rather than to reason about it at a high level, which was not his purpose in the book. Commented Apr 26, 2013 at 14:39
  • 1
    This is why my school offered a historical computing class where you get to program an Altair and some PDPs.
    – Rig
    Commented Apr 26, 2013 at 17:21
  • @Rig - seriously? Now I feel old. Although not as old as explaining HPGL to a new hire and discovering they had never seen or heard of a pen plotter! Commented Apr 26, 2013 at 21:52
  • 6
    +1 because of the amusing rant as well as relevant info. Commented Apr 27, 2013 at 3:30

Knuth discusses his reasoning in the Preface. I'll quote just a few bits and pieces:

...I needed to decide whether to use an algebraic language such as ALGOL or FORTRAN, or to use a machine-oriented language for this purpose. Perhaps many of today's computer experts will disagree with my decision to use a machine-oriented language, but I have become convinced that it was definitely the correct choice, for the following reasons:

  1. Algebraic languages are more suited to numerical problems than the nonnumerical problems considered here. [ ... ]
  2. ...By writing in a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality.
  3. The programs we require are, with few exceptions, all rather short...
  4. A person who is more than casually interested in computers should be well schooled in machine language...
  5. Some machine language would be necessary anyway...

Although he doesn't point it out directly, I think his mention of ALGOL and FORTRAN points to another problem he avoided that may be even more important. Let's assume he had chosen Algol (clearly better suited to non-numeric programs than Fortran anyway). I would posit that Algol would probably be even more foreign to most of today's programmers than the assembly language he chose.

For the third edition, he redesigned the MIX to fit more closely with modern processors, and had to rewrite the code for it. I'd posit, however, that had he used a higher level language, the rewrite would have been substantially greater -- and all the reasons he gave would remain as well.

  • Also, compilers were typically expensive in those days. Years after TAOCP volume 1 came out, I interviewed at a place that didn't want to spend the money on one (and, to be honest, IBM 370 assembler wasn't that bad), and my wife worked at an assembly language shop quite a few years after that. Commented Apr 26, 2013 at 17:27
  • 2
    how can i upvote point 4??
    – Javier
    Commented Apr 27, 2013 at 1:50
  • 6
    @Javier get a copy and write +1 in the margin. Commented Apr 27, 2013 at 3:32

Knuth has updated his rationale as well:

Why have a machine language?

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 many of the software programs 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 TAOCP, and I will 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 RISC machines is pleasant and simple, when the RISC machine has a nice clean design. So I need not dwell on arcane, fiddly little details that distract from the main points. In this respect MMIX will be significantly better than MIX.

Not the answer you're looking for? Browse other questions tagged or ask your own question.