La petite bête

Contrairement à ce qu'avaient l'air de penser certains informaticiens que j'ai rencontrés, il n'y a rien de masochiste à s'intéresser à l'assembleur lors d'un développement dans un langage évolué. En fait, cela peut rendre pas mal de services. Suivant le principe d'après lequel tout ne vous apparaît pas obligatoirement, vous pouvez vous rendre compte lors de la recherche d'un problème à l'aide d'un debugger que les choses vont de travers mais que le déroulement pour lequel chaque ligne du fichier source est traitée d'un bloc (pas à pas traditionnel) ne permet pas de voir pourquoi.

Cela peut par exemple se produire dans une expression d'un programme en C. Ce langage dispose de nombreux opérateurs, certains tout à fait courants comme +, -, *, /, d'autres beaucoup plus exotiques. Ils sont répartis en un nombre non négligeable de niveaux de priorités (la multiplication est prioritaire sur l'addition comme cela est habituel mais où le test d'égalité se situe-t-il dans la hiérarchie ?). Mettons que vous écriviez un jour en C une expression complexe et qu'emporté par l'enthousiasme vous vous trompiez dans une ou plusieurs priorités et ne mettiez pas de parenthèses pour éclaircir la situation. Même en vous rendant compte que c'est de cette ligne que viennent vos ennuis, vous risquez de passer un certain temps avant de trouver la correction à apporter, surtout si vous ne remettez pas en question la priorité de chaque opérateur par rapport aux autres, ce qui est à la base de la façon dont vous visualisez la résolution de l'expression.

Avec un bon debugger il est possible de passer de la représentation en langage évolué (ce que vous avez vous-même écrit) vers une vue en assembleur (éventuellement mixée avec les lignes du source pour se repérer plus facilement). A ce moment vous pouvez avancer instruction par instruction dans le code assembleur et détailler pour chacune ce qui s'y passe, ce qui signifie que vous ne verrez pas de niveau plus élémentaire. Si l'ordre des opérations n'est pas celui que vous attendiez vous vous en rendrez compte assez rapidement. Il n'est pas nécessaire d'être un spécialiste de l'assembleur pour le faire parce que normalement tout apparaît : le code, les registres du microprocesseur, la mémoire accédée… Il suffit de connaître l'organisation des registres, les modes d'adressage et les instructions courantes (cela doit pouvoir se trouver sur Internet) et même sans être sûr on peut approfondir au cas par cas.

J'ai vu certains bugs qu'il était pratiquement impossible de dénicher sans passer en assembleur. Personnellement il me semble raisonnable de détailler au maximum les choses de cette manière dès qu'apparaît un mystère. Le C n'est pas avare de cas tordus, comme le programme suivant qui affiche un résultat erroné seulement dans certains cas et pour certains compilateurs, sans que cela vienne d'un bug de la bibliothèque standard. Les développeurs C qui n'en savent pas la raison à l'avance peuvent se pencher dessus pour se faire une idée des ennuis qu'un examen à la loupe permet éviter.

#include <stdio.h>

main()

{
char	Chaine[20];
long	l;

scanf("%s",Chaine);
l = atol(Chaine);
printf("%ld\n",l);
}

Quand on travaille en C++ cela est même encore plus utile pour anticiper ultérieurement le déroulement des programmes parce que ce langage comporte certains mécanismes implicites qui ne sont pas évidents. Ainsi, la connaissance du principe des fonctions virtuelles ou la différence concrète entre une fonction statique et celles qui ne le sont pas peut aider à élucider des situations étranges au premier abord.