Des zéros et des uns

Vous le savez sans doute, l'informatique, « c'est que des zéros et des uns ». Mais quand vous regardez votre écran, vous avez sans doute du mal à voir quel est le rapport entre votre super logiciel et des zéros et des uns.

Les zéros et les uns, c'est effectivement la base de tout dans un appareil informatique (ordinateur, téléphone, télé connectée, bref, tout ce qui contient un microprocesseur).

Mais demander où sont les zéros et les uns quand on regarde un écran, c'est comme demander où sont les atomes quand on regarde une maison.

Voyons voir comment on construit une maison (un logiciel) à partir d'atomes (des zéros et des uns).

Un processeur, ça contient plein de petites choses qui s'appellent des transistors.

Un transistor, dans le contexte, ça permet de stocker une information simple : ouvert ou fermé ; courant qui ne passe pas, courant qui passe ; faux ou vrai. Bref, zéro ou un.

(Voir l'article Bit, Byte, Bitten.)

On peut assez facilement comprendre comment on utilise ça pour stocker des informations complexes : on utilise un codage interprété par l'ordinateur.

C'est comme ça que naissent les formats de fichier.

Un fichier, c'est une suite de bits auquel on va donner un sens selon une norme prédéfinie : le format (par exemple HTML, MP3, WAV, JPEG, etc.).

Bien sûr, il y a des formats plus complexes ou compressés, mais le principe reste le même :

une suite de bits, c'est une information qu'on interprète différemment selon le contexte.

D'accord pour le stockage, mais le reste ? Un logiciel, ce n'est pas que du stockage, ce sont surtout des actions.

Eh bien, c'est le même principe que pour le stockage en utilisant encore un autre format :

au lieu de simplement interpréter les suites d'octets comme des textes à afficher, des vidéos à diffuser ou des musiques à jouer… l'ordinateur peut les interpréter comme des suites d'instructions.

C'est ce qu'on appelle un programme.

Et absolument tout ce que fait un ordinateur peut être décrit comme une trèèèèèèès longue suite d'instructions de ce genre.

(Voir l'article Les ordinateurs sont cons.)

Oui, alors bien sûr, on ne s'amuse jamais à développer un programme en écrivant chaque zéro et chaque un individuellement, tout comme on ne construit pas une maison atome par atome.

Mais le monde informatique est une création humaine et il faut donc quand même bien « inventer » ces briques de bases.

(Alors que dans le monde physique, elles sont déjà un peu assemblées par le hasard, par Dieu ou par quelle que soit l'explication de l'origine de l'Univers qui vous aide à dormir la nuit.)

Comme écrire des zéros et des uns, c'est assez illisible pour un être humain, on a inventé une façon un peu plus claire d'écrire des instructions :

C'est le langage le plus « bas niveau » (c'est-à-dire proche de la machine) qui existe après le binaire.

En gros, on a juste traduit les instructions binaires avec des mots-clefs.

Ici, on a une simple correspondance, SET A 126 -> 0010 1000 0111 1110. Mais tous les processeurs n'ont pas les mêmes instructions disponibles ! Il y a donc plusieurs langages assembleurs…

Bien sûr, ça reste très compliqué d'écrire des choses un peu conséquentes dans un langage si bas niveau.

Quand j'étais en école d'ingénieur, notre premier TP d'assembleur, c'était 4 heures pour coder… une multiplication.

Du coup, ce qu'on code en assembleur, ce sont des briques élémentaires un peu plus grosses que les instructions de bases, briques qu'on va réutiliser intensivement.

C'est ce qui va donner les langages de programmation, qui nécessitent d'être transformés en binaire par une opération complexe (la compilation ou l'interprétation selon les langages) et pas simplement « traduits » mot à mot comme l'assembleur.

On a quitté le monde moléculaire pour arriver aux matières premières, au sable, à la terre, à l'eau…

Par exemple, ci-dessus, on avait un calcul de math un peu plus poussé qu'une simple addition mais qui est déjà précodé et disponible dans la bibliothèque standard du langage C.

Et à partir de là, on a tout ce qu'il faut pour construire une maison.

Notre langage et notre bibliothèque standard nous donnent peut-être accès aux matières premières, au sable, à la terre… mais on trouve des langages et des bibliothèques de plus haut niveau qui fournissent des fonctions beaucoup plus avancées (on serait au niveau du ciment, du plâtre, même des briques et du placo).

Très souvent, ces bibliothèques se basent sur les bibliothèques standards qui elles-mêmes sont basées sur des morceaux d'assembleurs qui se traduisent, pour finir, en binaire !

Voilà comment, au final, on construit des programmes complexes (des maisons) : en utilisant parfois des objets préconstruits (des poutres, des dalles) basés sur des fonctions complexes (du ciment, du plâtre) basées sur des fonctions simples (du sable, du bois), basées sur des morceaux de code très bas niveau (des molécules) qu'on peut traduire en une suite de bits : des zéros et des uns (des atomes).

Voilà. Nous avons à peu près fait le tour même si j'ai un peu simplifié.

On ne construit pas une maison en assemblant des atomes à la main, on ne construit pas un programme en écrivant des zéros et des uns à la main. Mais une maison, ça reste des atomes. Un programme, ça reste des zéros et des uns.

Notez, pour finir, que l'assembleur reste utilisé « à la main » pour des morceaux de code critiques (ou tout simplement pour optimiser les fonctions bas niveau), sans parler d'anciens programmes « conséquents » et développés quand même directement en assembleur (pour des raisons de performance, la plupart du temps).