Pourquoi Donald Knuth écrit-il TAOCP en utilisant le langage d'assemblage?

Je ne déteste pas utiliser le langage d'assemblage, car j'en ai écrit quelques-uns dans mon cours sur le système d'exploitation. Mais évidemment, le langage d'assemblage manque d'abstraction, il faut faire plus attention aux détails.

Le langage d'assemblage est-il vraiment essentiel pour écrire TAOCP?

Il utilise non seulement MIXAL, son langage d'assemblage pour MIX, mais aussi MIX, un modèle pour un ordinateur simple (comme celui qui était utilisé dans les années soixante). Il s'agit d'un modèle d'enseignement avec lequel il est, dans une certaine mesure, indépendant du développement sur le terrain.

S'il avait utilisé un autre langage de programmation (lequel, au fait, pensez-vous aurait été approprié?), Par exemple NPL (langage de programmation astucieux), il aurait dû abandonner l'idée d'utiliser MIX ou introduire un compilateur d'un langage informatique de choix (ce qui est beaucoup plus complexe que ce qu'il traite dans le Vol 1). De cette façon, il ne serait pas devenu TAOCP mais TAONPLP. Le premier est indépendant d'un tel choix et, pour cette raison, intemporel d'une manière que peu de livres sur la programmation le seront jamais. Le deuxième serait probablement oublié maintenant ...

Aussi, tant que les ordinateurs fonctionnent en principe comme le fait son MIX, c'est une bonne chose d'en tenir compte si vous êtes vraiment intéressé à apprendre à travailler avec eux.

Vous, jeunes whippersnappers, vous m'émerveillez parfois. Vous n'avez trop souvent aucune idée que quelque chose s'est passé avant de commencer l'école. (J'ai le même problème. Il m'a fallu beaucoup de temps pour comprendre que 15 ans étaient en fait très peu de temps, du point de vue des adultes. C'est à peu près la durée allant d'Hiroshima à la crise des missiles cubains. Pour moi, la Seconde Guerre mondiale est juste l'histoire, mais mon père y a combattu, et ma mère était au collège pendant.)

TAOCP, vol. 1, "Fundamental Algorithms", 1ère édition, a été imprimé pour la première fois en 1968. Cela fait 45 ans. Knuth a commencé à planifier la série bien avant.

Pour référence: l'Intel 8086 est apparu pour la première fois en 1978, dix ans plus tard. La langue PASCAL est apparue pour la première fois en 1971; le livre Jensen & Wirth, sur la deuxième version du langage, est sorti en 1974. Le développement initial de C a été 1969-1973: K&R a été publié en 1978.

Knuth voulait que la série couvre le domaine. Il a défini le style, ALORS, pour être utile aux pratiquants ALORS. Il ne s'attendait jamais à ce que cette série devienne littéralement l'œuvre de sa vie, ou que son écriture s'étende sur ce qui durera probablement bien plus d'un demi-siècle quand il aura finalement terminé.

Le langage d'assemblage n'est sans doute pas aussi critique aujourd'hui qu'il l'était à l'époque, mais il est encore beaucoup plus important que les mavens Java / C ++ / Javascript / Python / Perl ne voudraient vous faire croire.

Maintenant sortez de ma pelouse!

Knuth discute de son raisonnement dans la Préface. Je ne citerai que quelques morceaux:

... Je devais décider d'utiliser un langage algébrique tel que ALGOL ou FORTRAN, ou d'utiliser un langage orienté machine à cet effet. Beaucoup d'experts en informatique d'aujourd'hui seront peut-être en désaccord avec ma décision d'utiliser un langage orienté machine, mais je suis devenu convaincu que c'était certainement le bon choix, pour les raisons suivantes:

1. Les langages algébriques sont plus adaptés aux problèmes numériques que les problèmes non numériques considérés ici. [...]
2. ... En écrivant dans un langage orienté machine, le programmeur aura tendance à utiliser une méthode beaucoup plus efficace; c'est beaucoup plus proche de la réalité.
3. Les programmes dont nous avons besoin sont, à quelques exceptions près, tous plutôt courts ...
4. Une personne qui s'intéresse plus que par hasard aux ordinateurs devrait être bien formée en langage machine ...
5. Un langage machine serait de toute façon nécessaire ...

Bien qu'il ne le signale pas directement, je pense que sa mention d'ALGOL et de FORTRAN indique un autre problème qu'il a évité et qui peut être encore plus important. Supposons qu'il ait choisi Algol (clairement mieux adapté aux programmes non numériques que Fortran de toute façon). Je dirais qu'Algol serait probablement encore plus étranger à la plupart des programmeurs d'aujourd'hui que le langage d'assemblage qu'il a choisi.

Pour la troisième édition, il a repensé le MIX pour l'adapter plus étroitement aux processeurs modernes et a dû réécrire le code pour cela. Je suppose, cependant, que s'il avait utilisé un langage de niveau supérieur, la réécriture aurait été beaucoup plus importante - et toutes les raisons qu'il a invoquées resteraient également.

Knuth a également mis à jour sa justification :

Pourquoi avoir un langage machine?

De nombreux lecteurs pensent sans doute: `` Pourquoi Knuth remplace-t-il MIX par une autre machine au lieu de simplement s'en tenir à un langage de programmation de haut niveau? Presque personne n'a recours aux assembleurs de nos jours. ''

Ces personnes ont droit à leurs opinions, et elles n'ont pas besoin de s'embêter à lire les parties en langage machine de mes livres. Mais les raisons du langage machine que j'ai données dans la préface du volume 1, écrit au début des années 1960, restent valables aujourd'hui:

• L'un des principaux objectifs de mes livres est de montrer comment les constructions de haut niveau sont réellement implémentées dans les machines, pas simplement de montrer comment elles sont appliquées. J'explique la liaison coroutine, les structures arborescentes, la génération de nombres aléatoires, l'arithmétique de haute précision, la conversion radix, le regroupement des données, la recherche combinatoire, la récursivité, etc., à partir de zéro.
• Les programmes nécessaires dans mes livres sont généralement si courts que leurs principaux points peuvent être facilement compris.
• Les personnes qui sont plus que par hasard intéressées par les ordinateurs devraient avoir au moins une idée de ce à quoi ressemble le matériel sous-jacent. Sinon, les programmes qu'ils écrivent seront assez étranges.
• Le langage machine est nécessaire dans tous les cas, en tant que sortie de la plupart des logiciels que je décris.
• L'expression de méthodes de base telles que des algorithmes de tri et de recherche en langage machine permet de mener des études significatives sur les effets du cache et de la taille de la RAM et d'autres caractéristiques matérielles (vitesse de la mémoire, pipelining, problème multiple, tampons d'aspect, taille des blocs de cache, etc.) lors de la comparaison de différents régimes.

De plus, si j'utilisais une langue de haut niveau, quelle langue devrait-elle être? Dans les années 1960, j'aurais probablement choisi Algol W; dans les années 1970, j'aurais alors dû réécrire mes livres en utilisant Pascal; dans les années 80, j'aurais sûrement tout changé en C; dans les années 90, j'aurais dû passer en C ++ puis probablement en Java. Dans les années 2000, une autre langue sera sans doute de rigueur. Je n'ai pas le temps de réécrire mes livres au fur et à mesure que les langues se démodent; les langues ne sont pas le point de mes livres, le point est plutôt ce que vous pouvez faire dans votre langue préférée. Mes livres se concentrent sur des vérités intemporelles.

Par conséquent, je continuerai à utiliser l'anglais comme langue de haut niveau dans TAOCP, et je continuerai à utiliser un langage de bas niveau pour indiquer comment les machines calculent réellement. Les lecteurs qui ne veulent voir que des algorithmes déjà emballés sous forme de plug-in, en utilisant un langage à la mode, devraient acheter des livres d'autres personnes.

La bonne nouvelle est que la programmation des machines RISC est agréable et simple, lorsque la machine RISC a un design épuré et agréable. Je n'ai donc pas besoin de m'attarder sur les petits détails obscurs qui ne détournent pas l'attention des points principaux. À cet égard, MMIX sera nettement meilleur que MIX.