Ce que le compilateur écrit

Une fonction Python n'est pas exécutée telle qu'elle est écrite

Soit la plus petite fonction utile qui soit : elle retire une correction fixe à une mesure.

Le module dis de la bibliothèque standard affiche ce que l'interpréteur exécute réellement. La sortie ci-dessous vient de CPython 3.14.7 ; les noms d'instructions changent d'une version à l'autre, et une version plus ancienne en donnerait d'autres.

  1           RESUME                   0

  2           LOAD_FAST_BORROW         0 (mesure)
              LOAD_SMALL_INT           4
              BINARY_OP               10 (-)
              RETURN_VALUE

La colonne de gauche est le numéro de ligne du fichier source. Le reste est une suite d'instructions, et elle se lit exactement comme un programme de ce module : une opération élémentaire par ligne, exécutées dans l'ordre. RESUME est une formalité d'entrée de fonction, sans effet observable ici.

Les trois instructions qui comptent méritent d'être lues avec attention, parce qu'il leur manque quelque chose. LOAD_FAST_BORROW 0 charge la variable locale numéro 0, c'est-à-dire mesure. La charge où ? L'instruction ne le dit pas. LOAD_SMALL_INT 4 charge la constante quatre. Au même endroit non nommé. BINARY_OP 10 (-) fait une soustraction, mais ne nomme ni ses deux sources ni sa destination.

C'est là toute la différence avec ce que les neuf chapitres précédents ont montré. sub t0, a0, a1 nomme trois cases. BINARY_OP - n'en nomme aucune. Les deux instructions font la même soustraction.

Le prix d'une pile, mesuré

Rien n'empêche de faire tourner une machine à pile sur une machine à registres : il suffit de se donner une pile, et RISC-V en a une depuis le chapitre 8. La figure suivante traduit les quatre instructions Python ci-dessus, une par une, sans rien simplifier. Chaque commentaire porte le nom de l'instruction Python qu'il réalise.

Douze instructions, et sp qui remonte et redescend six fois. Sur une machine à registres, la même fonction s'écrit en une seule instruction, addi a0, a0, -4, qui ne touche ni la mémoire ni la pile. L'écart n'est pas une curiosité : c'est exactement ce que fait un interpréteur Python à chaque tour de boucle, et c'est une des raisons pour lesquelles une boucle Python est lente comparée à la même boucle compilée.

La pile n'est pourtant pas une erreur de conception. Une instruction qui ne nomme aucun registre tient dans un octet, là où une instruction RISC-V en occupe quatre ; un bytecode compact se transporte mieux, et surtout il se produit sans avoir à répondre à la question la plus pénible de la compilation : quelle valeur mérite de rester dans un registre, et laquelle doit retourner en mémoire. Une machine à pile n'a pas à en décider, puisqu'elle n'a pas de registres à distribuer.

Trois lignes Python, trois lignes d'assembleur

La fonction suivante calcule la même chose que l'exemple du chapitre 1, avec des étapes intermédiaires nommées.

Son bytecode montre une seconde famille d'instructions, celles qui rangent.

  1           RESUME                   0

  2           LOAD_FAST_BORROW_LOAD_FAST_BORROW 1 (mesure, offset)
              BINARY_OP               10 (-)
              STORE_FAST               2 (ecart)

  3           LOAD_FAST_BORROW_LOAD_FAST_BORROW 34 (ecart, ecart)
              BINARY_OP                0 (+)
              STORE_FAST               3 (double)

  4           LOAD_FAST_BORROW         3 (double)
              LOAD_SMALL_INT           2
              BINARY_OP               10 (-)
              RETURN_VALUE

STORE_FAST 2 retire la valeur du sommet de la pile et la range dans la case locale numéro 2. Les variables locales, elles, sont bien numérotées : ce sont des cases fixes, désignées par un indice, et non par leur nom, qui n'existe plus qu'entre parenthèses pour la lisibilité de l'affichage. La pile ne sert donc qu'aux valeurs en cours de calcul, jamais au stockage durable.

Un détail mérite d'être relevé, parce qu'il annonce tout le reste du chapitre. LOAD_FAST_BORROW_LOAD_FAST_BORROW n'est pas une instruction d'un manuel : c'est deux chargements fusionnés en un seul, décidés par le compilateur de CPython parce qu'ils se suivaient. Le texte source ne le demandait pas, et le programmeur ne l'a pas écrit. C'est une optimisation, visible à l'œil nu dans la sortie de dis.

La traduction vers une machine à registres n'a besoin d'aucune pile, parce qu'il y a assez de registres pour tenir les trois étapes.

Trois instructions RISC-V pour trois lignes de Python, contre dix instructions de bytecode pour les mêmes trois lignes. La correspondance n'est presque jamais aussi nette, mais l'ordre de grandeur, lui, est fidèle : là où la machine à registres range un résultat intermédiaire dans t0 et l'y laisse, la machine à pile l'empile, le dépile, le range dans sa case locale et ira l'y rechercher.

Le compilateur choisit, et pas comme un humain

Le cas intéressant n'est pas la ligne isolée, c'est la boucle, parce que c'est là que se joue tout ce qu'un compilateur sait faire.

  1           RESUME                   0

  2           LOAD_SMALL_INT           0
              STORE_FAST               1 (total)

  3           LOAD_SMALL_INT           1
              STORE_FAST               2 (i)

  4   L1:     LOAD_FAST_BORROW_LOAD_FAST_BORROW 32 (i, n)
              COMPARE_OP              58 (bool(<=))
              POP_JUMP_IF_FALSE       20 (to L2)
              NOT_TAKEN

  5           LOAD_FAST_BORROW_LOAD_FAST_BORROW 18 (total, i)
              BINARY_OP                0 (+)
              STORE_FAST               1 (total)

  6           LOAD_FAST_BORROW         2 (i)
              LOAD_SMALL_INT           1
              BINARY_OP                0 (+)
              STORE_FAST               2 (i)
              JUMP_BACKWARD           25 (to L1)

  7   L2:     LOAD_FAST_BORROW         1 (total)
              RETURN_VALUE

Deux choses sautent aux yeux, et les deux ont été rencontrées au chapitre 6. JUMP_BACKWARD est un saut arrière, et il est la boucle : l'interpréteur ne connaît pas plus le mot while que le processeur. POP_JUMP_IF_FALSE est le saut conditionnel qui en sort. La structure est celle d'un programme RISC-V, au vocabulaire près.

La troisième chose demande d'y regarder à deux fois : à chaque tour, total est rechargé de sa case locale, additionné, puis rangé dans sa case locale. Pareil pour i. Six accès à des cases nommées par tour de boucle, pour deux additions. Rien dans le texte Python ne demande cela ; c'est la conséquence directe du modèle à pile, où une valeur qui doit survivre à la fin d'une expression n'a pas d'autre endroit où se tenir.

La même fonction dans un langage système

Voici la même chose en C, langage que ce cours ne demande pas de connaître. Chaque ligne est commentée, et rien n'est à en retenir sinon la forme générale.

Un compilateur peut traduire ce texte de deux façons très différentes, et le choix ne dépend pas du programme mais du niveau d'optimisation demandé. Les deux figures suivantes donnent ces deux traductions, écrites à la main pour ce cours.

La première suit l'habitude du bytecode : total et i vivent en mémoire, et chaque tour va les y chercher.

Un détail de cette figure mérite un mot au passage : la colonne des instructions réelles montre que la t3, total produit un lui suivi d'un addi zero, zero, 0, c'est-à-dire d'un nop. L'adresse visée tombe pile sur un multiple de 4096, la seconde moitié du raccourci n'a donc rien à ajouter, et l'assembleur laisse une instruction sans effet plutôt que de décaler tout ce qui suit.

La seconde traduction garde les deux variables dans des registres, et ne touche plus la mémoire du tout.

Les deux figures donnent 15, ce qui était attendu. Elles ne mettent pas le même temps à y arriver : cinquante-deux pas pour la première, vingt-quatre pour la seconde. Le corps de boucle passe de neuf instructions à quatre, parce que six accès mémoire ont disparu. Aucune ligne du programme source n'a changé ; seule la question « où vit cette variable » a reçu une autre réponse.

C'est, très exactement, ce qu'un compilateur fait en passant d'un niveau d'optimisation à un autre. Sans optimisation, il range chaque variable locale dans la pile et la relit à chaque usage, parce que c'est simple, régulier, et que le débogueur peut alors montrer la valeur de n'importe quelle variable à n'importe quel instant. Avec optimisation, il garde en registre ce qui sert souvent, et la variable, en tant qu'emplacement mémoire, cesse d'exister.

Ce que le compilateur s'autorise encore

Garder une variable en registre est le choix le plus visible, mais ce n'est pas le seul. Trois autres reviennent constamment, et se reconnaissent dans un désassemblage.

Le calcul sorti de la boucle : une expression dont les sources ne changent pas d'un tour à l'autre est calculée une fois avant d'entrer. Le programme source la répète à chaque tour, l'assembleur produit ne la contient qu'une fois, et le compte des instructions ne correspond plus au compte des lignes.

Le calcul fait d'avance : quand toutes les sources d'un calcul sont connues au moment de la compilation, le résultat est écrit directement dans le programme. Une fonction qui ne fait qu'additionner deux constantes peut se réduire à ranger la somme, et l'addition disparaît du binaire.

Le réordonnancement : l'ordre des instructions produites n'est pas celui des lignes écrites. Un compilateur peut avancer un chargement mémoire de plusieurs instructions, pour que la valeur soit arrivée quand elle sera utilisée, tant que cela ne change rien au résultat observé par ce programme, seul. Ce dernier mot compte : la garantie porte sur un fil d'exécution isolé, et cesse dès que deux traitements partagent une donnée.

Savoir lire une trace

Un dernier usage, moins spectaculaire mais plus fréquent : lire ce qu'un outil affiche quand un programme s'est arrêté brutalement. Une trace d'exécution ne donne ni les noms de variables ni les lignes de code, mais des adresses, des noms de fonctions et des décalages. Trois habitudes suffisent à en tirer quelque chose.

D'abord, une adresse de la forme nom_de_fonction+0x2c indique une position à l'intérieur d'une fonction, mesurée en octets depuis son début. Divisée par quatre sur une machine RISC-V, elle donne un rang d'instruction, pas un numéro de ligne.

Ensuite, le registre qui contient l'adresse de retour dit d'où l'appel venait. Le chapitre 9 a montré que cette adresse est rangée sur la pile dès qu'une fonction en appelle une autre : c'est ce chaînage que les outils remontent pour reconstituer la suite des appels.

Enfin, une adresse invraisemblable, très petite ou manifestement pas un multiple de quatre, n'est pas un mystère mais un indice : quelque chose a écrit là où il ne fallait pas, et le chapitre 9 a montré exactement comment une écriture trop longue dans une variable locale atteint l'adresse de retour posée juste à côté.

La méthode

1. Désassembler avant de supposer : dis.dis(fonction) sur une fonction Python donne la suite réellement exécutée, en quelques secondes, sans outil extérieur.
2. Lire le bytecode comme une pile : suivre à la main ce que chaque instruction empile et dépile, et vérifier qu'il ne reste qu'une valeur au moment du RETURN_VALUE.
3. Repérer les sauts avant tout le reste : JUMP_BACKWARD marque une boucle, POP_JUMP_IF_FALSE sa condition de sortie. La structure du programme s'en déduit sans lire les calculs.
4. Compter les accès mémoire d'un corps de boucle plutôt que ses lignes, puisque c'est ce compte qui sépare deux traductions du même code.
5. Vérifier la version de l'outil avant de citer une sortie de dis : les noms d'instructions changent d'une version de CPython à l'autre, et une sortie recopiée d'ailleurs peut être invérifiable.
6. Se méfier de la correspondance ligne à ligne quand l'optimisation est active : une variable peut avoir disparu, un calcul avoir été sorti d'une boucle, et un point d'arrêt tomber ailleurs que là où il est posé.

Synthèse

• Le bytecode de CPython est une suite d'instructions élémentaires pour une machine à pile : ses opérations ne nomment pas leurs opérandes, qu'elles prennent et reposent au sommet d'une pile.
• Une machine à registres fait l'inverse : elle nomme chaque case et n'impose pas d'ordre d'arrivée. Traduire fidèlement quatre instructions de bytecode vers RISC-V coûte douze instructions, là où la même soustraction tient en une seule.
• La même fonction se traduit de deux façons selon que ses variables vivent en mémoire ou en registre : cinquante-deux pas contre vingt-quatre pour la boucle du chapitre, à résultat identique.
• Un compilateur décide seul de ce qui reste en registre, de ce qui sort d'une boucle, de ce qui se calcule d'avance et de l'ordre des instructions produites. Aucune de ces décisions n'apparaît dans le texte source.
• Une variable gardée en registre n'a pas d'adresse, ce qui explique le <optimized out> d'un débogueur et la différence de confort entre une compilation de mise au point et une compilation de production.
• La liberté de réordonner repose sur l'hypothèse d'un fil d'exécution unique, et cesse de valoir dès que deux traitements partagent une donnée.
• Lire une trace d'exécution demande trois réflexes : interpréter fonction+0x2c comme un décalage en octets, remonter les adresses de retour empilées, et reconnaître une adresse invraisemblable comme la marque d'une écriture hors limites.

Ce chapitre a montré une seconde façon d'écrire les mêmes calculs, celle de la machine à pile. Un autre alphabet en montre une troisième, celle des processeurs qui équipent la plupart des machines de bureau, et apprend à la lire sans la parler.