Ainsi, un 'A' est encodé sur un octet par le code 65, en hexa 0x41, donc en binaire 0100 0001
Voila, ça c'est fait.
Maintenant, l'assembleur, ça n'a pas grand chose à voir avec l'ASCII, c'est juste des mnémoniques MOV, ADD, etc... qui ont elles aussi un codage. Le code binaire associé s'appelle l'Opcode.
Chaque instruction fait donc un certain nombre de bits, et elles passent les unes à la suite des autres dans le processeur.
j'ai déjà vu ce site hier, et je n'ai pas saisi comment sont calculés les traductions en ASCII et comment à partir d'un ASCII ont obtient le caractère associé car c'est surtout la correspondance automatisé entre ASCII et caractère classique qui m'intéresse.
De plus, plus secondaire :
comment l'ASCII est-il utilisé dans le PC ?Et l'assembleur ? pour l'assembleur, j'imagine que ça demanderait des heures , mais j'aimerais juste comprendre le principe global d'utilisation de l'assembleur dans le PC ?
j'ai déjà vu ce site hier, et je n'ai pas saisi comment sont calculés les traductions en ASCII et comment à partir d'un ASCII ont obtient le caractère associé car c'est surtout la correspondance automatisé entre ASCII et caractère classique qui m'intéresse.
C'est une simple table de correspondance entre une valeur et un symbole.
Il y a bien longtemps de cela (note que c'est encore le cas pour le BIOS, entre autres), les caractères étaient connus de l'ordinateur sous la forme d'une matrice de 8x8 bits dont l'état indiquait le pixel de l'écran qu'il fallait "allumer"
Ainsi, le A majuscule était codé sous une form proche de
00000000
111
1 1
1 1
1 1
11111
1 1
111 111
(les espaces vides correspondent à un 0)
Quand l'ordinateur voyait que l'on voulait afficher le caractère "numéro 66", il allait chercher dans la table de correspondance la matrice la matrice de 8x8 bits qui se trouvait à la position ... 66 et trouvait cette matrice bien particulière, qu'il envoyait pour affichage à l'écran.
Et, pour être tout à fait complet, il faut savoir que le "code ASCII" existait bien avant les ordinateurs. Il a été créé au départ pour les téléscripteurs: l'émetteur envoyait sur les fils des séquences de bits (8 à la fois) qui indiquaient le code du caractère à utiliser et le récepteur utilisait ce code pour sélectionner la position d'une boule qui contenait tous les caractères en "volume" (je crois qu'on appelait cela une "tulipe") avant d'aller frapper un ruban encreur qui allait "déposer" la marque (à l'encre) du caractère en question sur une feuille (un peu comme le faisaient certaines machines à écrire )
Grâce à cela, il était possible de faire transiter des textes entiers d'un point à l'autre du pays
Quand les "premiers" ordinateurs ont commencé à traiter autre chose que des valeurs numériques, et qu'ils ont du se mettre à afficher du texte, ils ont "logiquement" décidé d'utiliser la même table d'équivalence parce qu'ils avaient les mêmes besoins que les téléscripteurs et qui plus est une norme du standard américain (ANSI).
Quand on parle d'assembleur, on mélange bien souvent deux choses distinctes mais très proche:
le langage assembleur, qui est un langage de programmation "comme un autre" (à ceci près qu'il a été le premier à être créé :D) et
le programme assembleur, qui va se charger de traduire le code écrit en ... assembleur (le langage) en un ensemble d'insttructions qui seront compréhensibles par le processeur.
Pour comprendre exactement ce qui se passe, un petit cours d'histoire s'impose.
Flash Back:
Nous sommes en pleine seconde guerre mondiale. le principe de la fission nucléaire est connu depuis plusieurs années, et les américains veulent créer une arme suffisamment puissante pour forcer Hiro Hitto à capituler.
Pour ce faire, ils ont lancé un projet ultra secret: le projet Manhatan pour développer une bombe d'une puissance inégalée (la bombe atomique).
De très nombreux calculs sont nécessaires et des "super calculateur" sont utilisés. A l'époque, il fallait littéralement connecter les différentes étapes que le super calculateur devait suivre à l'aide de fils de cables. C'est un travail long, fastidieux, et source d'erreurs.
Les années passent:
La guerre est finie. Les américains ont lancé la bombe atomique sur Hiroshima, et, pour faire bonne mesure, en ont lancé une sur Nagazaki.
Ils ont gagné la guerre du pacifique et ils nous ont donné un (très sérieux) coup de main contre Hitler.
Jhon VonNeumann (qui a participé au projet Manhatan) a une idée de génie dans un rapport sur l'utilisatation de l'EVDAC en 1945: et si, au lieu de devoir "assembler" manuellement les instructions que le super calculateur doit suivre, nous faisions en sorte que le super calculateur dispose d'origine d'un certain nombre d'instructions qu'il pourrait réutiliser à la demande?
Cela nous permettrait d'introduire les instructions au fur et à mesure, et -- pourquoi pas -- de fournir des données par la même occasion. Et cela faciliterait le travail d'encodage.
Le principe des ordinateurs tels que nous les connaissons encore aujourd'hui était né.
A l'époque, le jeu d'instructions était relativement restreint, ainsi que la "taille" des données que nous pouvions faire "ingérer" par l'ordinateur.
Je n'ai plus les chiffres exacts en tête, mais si je me souviens bien, un ensemble composé d'une instruction et d'une donnée à fournir à l'instruction était codé sur quelque chose comme 20 bits : 8 bits pour représenter l'instruction (appelons la "opcode" pour "code d'opération") et 12 bits pour représenter la donnée. Cela donnait quelque chose comme
opération | donnée
010101111 | 011100111100
Grâce à cela, il devenait "plus facile" (et surtout plus rapide) d'indiquer à l'ordinateur ce que l'on voulait faire. Mais il suffisait que l'on se trompe sur un bit, et c'était la catastrophe
C'est dans ce contexte que l'assembleur est apparu.
Le langage permettait au développeur d'utiliser des mnémonique (LDAA pour "LoaD Acumulateur A") qui étaient traduits en en instructions compréhensibles par l'ordinateur grâce au programme assembleur.
Parallèlement à cela, un autre programme est apparu: un loader, écrit en langage machine, qui permettait à l'ordinateur de faire "tourner" le programme assembleur, et donc de comprendre le code qui était écrit par les développeurs.
A partir de là, les choses ont été de plus en plus vite:
Entre 1950 et 1964, ce n'est pas moins de 13 langages différents qui verront le jour (parmi lesquels des noms mythiques comme FORTRAN, COBOL, LISP ou simula)
Entre 1967 et 1978 on a vu apparaitre C, SQL, smaltalk et prolog
Dans les années 80, ca a été le tour (entre autres) de C++, ada, eifel et perl
et la liste n'a pas cessé de s'allonger depuis...
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html