The valuable prose aside, I never liked that code examples were in a pseudo assembly language.

jll29 13 minutes ago | parent | next [-]

I agree with that opinion. He started writing TAOCP in 1968, and could have switched to Pascal in 1972.

Pascal is simple and clear, and can be translated easily to anything from LISP, Fortran, Python to C or C++ (in fact, subsets of Pascal are often used as sample language in books about compilers, including in Pascal inventor N. Wirth's own compiler book (which, unlike Knuth's, was completed timely):

Wirth, Niklaus, Compilers (1996), 101pp., 2rd revision, 2017, online: https://people.inf.ethz.ch/wirth/CompilerConstruction/Compil..., last accessed 2026-07-07).

It does not matter that Pascal is not much in use anymore, because due to its readability, it's timeless. It nearly reads like English prose, yet is automatically executable. It has also been standardized, and there is a book-sized language description available, as are several -- commercial and open source -- implementations.

In contrast, his pseudo-assembler is arcane. Whenever I wanted to implement an algorithm following Knuth TACOP, I had to work off his English pseudo-code description rather than the associated pseudo-assembler code.

▲

commandlinefan 3 hours ago | parent | prev | next [-]

There are M/MIX assemblers and interpreters you can download and run - in some ways they're better than "real" programming languages because they're explicitly for instruction so usability concerns like package managers and build automation support don't get in "the way" of operating them.

▲

mghackerlady 3 hours ago | parent | prev | next [-]

It's the only thing he could've done if he wanted the books to stand the test of time

▲

convolvatron 3 hours ago | parent | prev [-]

consider the alternatives. it could have been written in PL-1 and rapidly become dated. or it could have been written in a slightly higher level custom language and that would also have to be taught and would be less clear about what was going on under the hood. or a kind of pseudo-code that would also admit ambiguity. or it could have been rewritten in pascal, and then java, and then javascript and then rust.

given the timespan and the focus on complete analysis of running times and not just asymptotics, in the end maybe it wasn't so terrible a choice.

▲

jcranmer an hour ago | parent [-]

Well, even as-is, it turns out that the kind of assembly language that Knuth originally wrote it in itself had a very short lifespan. MIX assumes a single accumulator register for arithmetic, which hasn't been a common processor architecture since around the 1980s. MMIX is redesigned to be more RISC, but it also uses a dynamic register window concept (which itself I think was only used on Itanium, and we all know how that architecture went down).

And unfortunately, for a lot of modern algorithms, you're going to have dive into SIMD-like algorithms, something MMIX doesn't have. Also, a lot of modern processors have a decent suite of bitwise operations (e.g., count leading/trailing zeros/ones, popcount) that is also missing from MMIX.

The programming languages that are in favor may change from decade to decade, but so to does most of the assembly language techniques.

▲

compiler-guy 41 minutes ago | parent [-]

Sparc and Xtensa also have register windows, although each has a slightly different implementation.

They were all the rage for a while, because they make procedure calls fast but turn out to have subtle issues in highly-multithreaded scenarios.

	▲	jcranmer 10 minutes ago \| parent [-]
		The Sparc and Xtensa register windows are fixed-size, not dynamic like Itanium's.