Nombres flottants et processeurs

Par exemple, prenons le nombre -3141,5. Celui-ci sera codé par le nombre flottant suivant :

Ce nombre flottant utilise 23 bits pour la mantisse, 8 pour l'exposant et un bit de signe. Le décalage utilisé est de 127. Il s'agit d'un des types de flottant supportés par la norme IEEE 754 : le format simple précision.

Cette norme va en effet définir quatre types de flottants différents. Chacun de ces types de flottants pourra stocker plus ou moins de valeurs différentes. Ce qui différencie ces types de flottant, c'est simplement le nombre de bits utilisés pour la mantisse et l'exposant, ainsi que le décalage.

Voici quelques-uns de ces types de flottants :

Certains formats de flottants ne sont pas forcément supportés par les unités de calcul de notre processeur. Par exemple, certains ne supportent que les flottants simple précision et rien d'autre. Si un processeur ne supporte pas un format de flottant, il doit émuler son support, généralement par logiciel. Exemple : les premiers processeurs Intel ne géraient que les flottants double précision étendue.

De plus, certains processeurs gèrent des formats de flottants spéciaux qui ne font pas partie de la norme IEEE 754, même s'ils sont plus rares.

Pour les dénormaux, aussi appelés flottants dénormalisés, l'exposant auquel on a enlevé le décalage prend la plus petite valeur possible : en clair, l'exposant vaut zéro.

Ces flottants ont une particularité. On calcule leur valeur grâce à la formule suivante :

On n'a pas besoin d'ajouter 1 à la mantisse pour calculer avec.

Là encore, ces flottants dénormalisés ne sont pas forcément supportés par certains processeurs. Si le résultat d'un calcul est un nombre dénormalisé, notre processeur va générer ce qu'on appelle une exception matérielle : le processeur va interrompre temporairement l'exécution du programme en cours et va exécuter un petit programme capable de traiter l'exception. Dans notre cas, ce programme va émuler logiciellement le traitement de ces dénormaux.

Mais même lorsque la gestion des dénormaux est implémentée en hardware (comme c'est le cas sur certains processeurs AMD), celle-ci reste malgré tout très lente.

Le zéro est le second de ces flottants spéciaux. Il ressemble un peu aux flottants dénormalisés, à un détail près : la mantisse est nulle ! C'est la seule différence avec les autres flottants dénormalisés : l'exposant est bel et bien nul, et on n'a pas besoin d'ajouter 1 à la mantisse pour calculer sa valeur à partir de sa représentation en binaire.

Au fait, remarquez que le zéro est codé deux fois à cause du bit de signe. Si vous mettez l'exposant et la mantisse à la bonne valeur de façon à avoir zéro, le bit de signe pourra valoir aussi bien 1 que 0 : on se retrouve avec un kitxmlcodeinlinelatexdvp-0finkitxmlcodeinlinelatexdvp et un kitxmlcodeinlinelatexdvp+0finkitxmlcodeinlinelatexdvp.

La norme impose la présence de deux flottants représentant respectivement l'infini positif et l'infini négatif.

L'infini (kitxmlcodeinlinelatexdvp\inftyfinkitxmlcodeinlinelatexdvp) est codé de la façon suivante :

NaN est l'abréviation de « Not A Number », ce qui signifie : n'est pas un nombre. NaN est utilisée pour signaler des erreurs ou des calculs n'ayant mathématiquement pas de sens. Malgré son nom explicite, on peut faire des opérations avec NaN, mais cela ne sert pas vraiment à grand-chose : une opération arithmétique appliquée avec un NaN aura un résultat toujours égal à NaN.

Voici comment celui-ci est codé :

En fait, il existe différents types de NaN, qui différent par la valeur de leur mantisse, ainsi que par les effets qu'ils peuvent avoir. Pour avoir plus de renseignements, voir ce lien : Nan - Wikipédia.

Pour donner un exemple avec l'exception Inexact, on va prendre le nombre kitxmlcodeinlinelatexdvp0.1finkitxmlcodeinlinelatexdvp. Ce nombre ne semble pourtant pas méchant, mais c'est parce qu'il est écrit en décimal.

En binaire, ce nombre s'écrit comme ceci : kitxmlcodeinlinelatexdvp0 \hspace{1mm} . \hspace{1mm} 1100 \hspace{1mm} 1100 \hspace{1mm} 1100 \hspace{1mm} 1100 \hspace{1mm} 1100 \hspace{1mm} 1100...finkitxmlcodeinlinelatexdvp et ainsi de suite jusqu'à l'infini. Notre nombre utilise une infinité de décimales. Bien évidemment, on ne peut pas utiliser une infinité de bits pour stocker notre nombre et on doit impérativement l'arrondir.

Comme vous le voyez avec la dernière exception, le codage des nombres flottants peut parfois poser problème : dans un ordinateur, il se peut qu'une opération sur deux nombres flottants donne un résultat qui ne peut être codé par un flottant. On est alors obligé d'arrondir ou de tronquer le résultat de façon à le faire rentrer dans un flottant.

Pour éviter que des ordinateurs différents utilisent des méthodes d'arrondis différentes, on a décidé de normaliser les calculs sur les nombres flottants et les méthodes d'arrondis. Pour cela, la norme impose le support de quatre modes d'arrondis :

• Arrondir vers + l'infini ;
• vers - l'infini ;
• vers zéro ;
• vers le nombre flottant le plus proche.

L'exception Invalid operation est levée dans deux cas :

• des calculs ayant un résultat qui est un nombre complexe : kitxmlcodeinlinelatexdvp\hspace{1mm} \sqrt {-1} \hspace{1mm}finkitxmlcodeinlinelatexdvp , kitxmlcodeinlinelatexdvp\ln (-5)finkitxmlcodeinlinelatexdvp, et autres ;
• le calcul est une forme indéterminée.

Pour ceux qui ne savent pas trop ce que sont les formes indéterminées, voici en exclusivité la liste des calculs qui retournent NaN :

• kitxmlcodeinlinelatexdvp(+\infty) \hspace{1mm} - \hspace{1mm} (+\infty) \hspace{1mm}finkitxmlcodeinlinelatexdvp ;
• kitxmlcodeinlinelatexdvp0 \hspace{1mm} \times \hspace{1mm} \inftyfinkitxmlcodeinlinelatexdvp et kitxmlcodeinlinelatexdvp\infty \hspace{1mm} \times \hspace{1mm} 0finkitxmlcodeinlinelatexdvp ;
• dans certains cas,kitxmlcodeinlinelatexdvp\hspace{1mm} 0^{0} \hspace{1mm}finkitxmlcodeinlinelatexdvp , kitxmlcodeinlinelatexdvp\hspace{1mm} 1^{\infty} \hspace{1mm}finkitxmlcodeinlinelatexdvp, et kitxmlcodeinlinelatexdvp\hspace{1mm} \infty ^{0} \hspace{1mm}finkitxmlcodeinlinelatexdvp.

Les overflow et underflow sont beaucoup plus rares : un nombre flottant peu contenir aussi bien de nombres très grands que des nombres très petits. Par exemple, un flottant simple précision peut stocker des nombres pouvant aller jusqu'à kitxmlcodeinlinelatexdvp3.4028234 \times 10^{38}finkitxmlcodeinlinelatexdvp : difficile d'obtenir un overflow dans ces conditions.

Les registres de l'unité x87 sont gérés d'une manière assez inédite : ceux-ci forment ce qu'on appelle une pile de registres. Les processeurs qui gèrent leurs registres de cette manière sont très rares. Il faut aussi préciser que les autres unités de calcul d'un processeur x86 gèrent leurs registres différemment. Mais voyons un peu ce que cette pile de registres a de particulier.

Si vous souhaitez stocker un flottant dans un registre, vous ne pouvez pas décider dans quel registre celui-ci sera stocké : nos registres sont en effet organisés sous la forme d'une pile de registres que l'on remplit dans un ordre bien précis.

Tout d'abord, ces 8 registres sont ordonnés et numérotés de 0 à 7 : le premier registre est le registre 7, tandis que le dernier registre est le registre 0. Lorsque la FPU x87 est initialisée, ces 8 registres sont complètement vides : ils ne contiennent aucun flottant.

Si on veut ajouter des flottants dans nos registres, on doit les « remplir » dans un ordre de remplissage imposé : on remplit d'abord le registre 7, puis le 6, puis le 5, et ainsi de suite jusqu'au registre 0. Si on veut ajouter un flottant dans cette pile de registres, celui-ci sera stocké dans le premier registre vide dans l'ordre de remplissage indiqué au-dessus. Prenons un exemple, les 3 premiers registres sont occupés par un flottant et on veut charger un flottant supplémentaire : le 4^e registre sera utilisé pour stocker ce flottant.

La même chose existe pour le « déremplissage » des registres. Imaginez que vous souhaitez déplacer le contenu d'un registre dans la mémoire RAM et effacer complètement son contenu. On ne peut pas choisir n'importe quel registre pour faire cela : on est obligé de prendre le registre non vide ayant le numéro le plus grand.

Vous remarquerez sûrement que ce flottant est le dernier à avoir été dans cette « pile » de registres. Notre pile de registres est donc gérée par un algorithme de type LIFO : Last Input First Output : dernier entré, premier sorti.

Si vous avez bonne mémoire, vous vous souvenez sûrement de ce que j'ai dit sur les registres de la FPU : elle contient 3 registres spéciaux qui ne stockent pas de flottants, mais sont malgré tout utiles. Ces 3 registres portent chacun un nom : Control Word, Status Word et Tag Word. Voilà, les présentations sont faites !

On va commencer par vous détailler le registre Tag Word. Celui-ci est utilisé par le processeur pour savoir si un registre est vide ou non : avouez que c'est pratique pour gérer la pile de registres vue au-dessus. Ce registre contient 16 bits et pour chacun des 8 registres de données de la FPU, 2 bits sont réservés dans le registre Tag Word. Ces deux bits contiennent des informations sur le contenu du registre de données réservé.

• Si ces deux bits valent 00, le registre contient un flottant « normal » différent de zéro ;
• Si ces deux bits valent 01, le registre contient une valeur nulle : 0 ;
• Si ces deux bits valent 10, le registre contient un NAN, un infini, ou un dénormal ;
• Si ces deux bits valent 11, le registre est vide et ne contient pas de nombre flottant.

Passons maintenant au Status Word. Celui-ci fait lui aussi 16 bits et chacun de ces bits a une utilité particulière. On ne va en citer que quelques-uns.

Comme vous le voyez, le Status Word contient tout ce qu'il faut pour qu'un programme puisse comprendre la cause d'une exception.

Enfin, voyons le Control Word, le petit dernier. Celui-ci fait toujours 16 bits et contient lui aussi des bits ayant chacun une utilité précise. Beaucoup de bits de ce registre sont inutilisés et on ne va citer que les plus utiles.

Notre FPU est capable d'effectuer un certain nombre d'instructions sur ces registres : les instructions de base supportées par la norme IEEE 754. Mais elle est aussi capable d'en effectuer d'autres.

La FPU x87 dispose d'instructions de comparaisons compatibles avec la norme IEEE 754, capables de comparer le flottant au sommet de la pile avec un autre nombre qui peut être flottant ou entier !

Voici une liste de quelques instructions de comparaisons supportées par les FPU 87 :

• FCOM : compare le contenu du registre 0 avec une constante flottante ;
• FCOMI : compare le contenu des registres 0 et 1 ;
• FICOM : compare le contenu du registre 0 avec une constante entière ;
• FTST : compare le registre numéroté 0 avec la valeur 0.

On trouve aussi des instructions de calculs, bien évidemment compatibles avec la norme IEE754 :

• l'addition : FADD ;
• la soustraction FSUB ;
• la multiplication FMUL ;
• la division FDIV ;
• la racine carrée FSQRT ;
• des instructions de calcul de la valeur absolue (FABS) ou encore de changement de signe (FCHS).

Notre FPU implémente aussi des instructions non prévues dans la norme IEE754 telles que :

• le cosinus : instruction FCOS ;
• le sinus : instruction FSIN ;
• la tangente : instruction FPTAN ;
• l'arc tangente : instruction FPATAN ;
• ou encore des instructions de calcul de logarithmes ou d'exponentielles.

Il va de soi que ces instructions ne sont pas supportées par la norme IEEE 754 et que tout compilateur qui souhaite être compatible avec la norme IEEE 754 ne doit pas utiliser ces instructions de calcul non supportées.

Les instructions de calcul n'ayant besoin que d'un seul flottant pour s'exécuter (les instructions de calcul d'une tangente, d'une racine carrée et d'autres) vont utiliser le flottant situé au sommet de la pile. Les instructions qui ont besoin de deux flottants (multiplication, addition, soustraction et autres) vont agir différemment suivant la situation. Elles peuvent prendre les deux flottants les plus haut placés dans cette pile, prendre le flottant au sommet de la pile, utiliser une donnée en provenance de la mémoire, ou encore utiliser le flottant le plus haut placé et un flottant stocké dans l'importe quel registre de cette pile de registres.

En plus de ces instructions de calcul, notre FPU possède des instructions permettant de transférer des flottants entre la mémoire et les registres, ou entre registres. On peut citer par exemple

D'autres instructions existent qui chargent certaines constantes (PI, 1, 0, certains logarithmes en base 2) dans le registre au sommet de la pile de registres.

Chacun des registres de données vus plus haut stocke un nombre flottant codé sur 80 bits. Oui, vous avez bien lu, 80 bits et non 32 ou 64 : cette FPU calcule sur des nombres flottants double précision étendue et non sur des flottants simple ou double précision, qui ne sont pas gérés par la FPU x87.

Mais comment cette FPU fait-elle pour calculer avec des flottants simple et double précision ?

Tout se joue lors de l'accès à la mémoire avec l'instruction FLD : celle-ci se comporte différemment suivant le flottant qu'on lui demande de charger. En effet, cette instruction peut charger depuis la mémoire un flottant simple précision, double précision ou double précision étendue. Le format du flottant qui doit être chargé est stocké directement dans l'instruction. Je m'explique : une instruction machine est stockée en mémoire sous la forme d'une suite de bits, et pour certaines instructions, des bits supplémentaires sont ajoutés. Dans notre cas, ces bits optionnels servent à indiquer à notre instruction le format du flottant qu'elle doit charger.

La FPU x87 peut charger depuis la mémoire un nombre flottant 80 bits directement dans un registre. Pour les flottants 32 et 64 bits, la FPU va devoir effectuer une conversion de notre flottant simple ou double précision en un flottant 80 bits. Tous les calculs faits par notre FPU vont donner des résultats codés sur 80 bits, et ceux-ci restent codés sur 80 bits tant que ceux-ci sont stockés dans les registres de la FPU. Par contre, dès qu'il faut enregistrer un nombre flottant en mémoire RAM, les problèmes commencent. Si le flottant en question est stocké dans la mémoire sur 32 ou 64 bits, notre processeur doit convertir le contenu du registre dans le format du flottant en mémoire, histoire de conserver le bon format de base. Cette conversion est faite automatiquement par l'instruction d'écriture en mémoire utilisée. Par contre, si notre flottant est représenté en mémoire sur 80 bits, l'écriture en mémoire est directe : pas de conversion.

Et ces conversions posent problème : elles ne respectent pas la norme IEEE 754 !

Comparons un calcul effectué sur un processeur gérant nativement les formats 64 et 32 bits et ce même calcul exécuté par la x87. Sur le premier processeur, le calcul sera effectué sur des flottants simple ou double précision. Notre processeur va faire ses calculs sur notre flottant directement dans ses registres.

On se retrouve donc avec deux cas de figure :

• si un des résultats de ces calculs est un flottant, celui-ci sera directement codé sur 32 ou 64 bits sans arrondi ;
• si un de ces résultats n'est pas un flottant, celui-ci sera arrondi de façon à donner un résultat qui peut être contenu dans un flottant 32/64 bits. On a donc un seul arrondi : celui qui arrive lors des calculs.

Avec la x87, le scénario est différent. Nos flottants 32/64 bits sont convertis en un flottant x87 80 bits lorsque l'on charge ceux-ci depuis la mémoire. Le calcul est ensuite effectué sur des flottants 80 bits. Là encore, le résultat est soit un flottant x87, soit est arrondi pour donner un flottant x87.

Maintenant, si vous voulez enregistrer ce flottant x87 80 bits dans la mémoire, il va falloir convertir celui-ci dans son format de base : 32 ou 64 bits. Notre résultat se fait arrondir au flottant 32 ou 64 bits le plus proche. On se retrouve donc avec un arrondi supplémentaire : c'est le phénomène du double rounding (qui signifie double-arrondi en français).

Et rien n'implique que le résultat de ces deux conversions aurait donné le même résultat que le calcul effectué sur des flottants 64 bits avec un seul éventuel arrondi ! Le pire, c'est qu'on n'a aucune solution à ce problème, pour les calculs faits avec la FPU x87.

Pour citer un exemple, sachez que des failles de sécurité de PHP et de Java aujourd'hui corrigées et qui avaient fait la une de la presse informatique étaient causées par ces arrondis supplémentaires. Bien sûr, sachez que ce bogue a pu être reproduit sur de nombreux autres langages et n'était certainement pas limité au PHP ou au Java : c'est le non-respect de la norme IEE754 par notre unité de calcul x87 qui était clairement en cause.

Mais ces problèmes d'arrondis ne s'arrêtent pas là. Si une série de calculs est faite sur des flottants stockés dans l'un de ces 8 registres, les résultats intermédiaires auront une précision supérieure, et seul le résultat final, stocké en mémoire sera arrondi. Dans ces conditions, le résultat peut être différent de celui qu'on aurait obtenu en utilisant seulement des flottants 64 bits lors des calculs.

Par exemple, prenons le calcul de kitxmlcodeinlinelatexdvpefinkitxmlcodeinlinelatexdvp, la base des logarithmes népériens. Cette constante est égale à la somme de l'inverse des factorielles des nombres entiers kitxmlcodeinlinelatexdvpe = \sum_{n=0}^{\infty} \frac {1} {n!}finkitxmlcodeinlinelatexdvp.

Si vous calculez cette constante sur un ordinateur vous allez devoir effectuer le calcul suivant : kitxmlcodeinlinelatexdvp1 + \frac {1} {2!} + + \frac {1} {3!} + \frac {1} {4!} + \frac {1} {5!} + \frac {1} {6!} + ... + \frac {1} {k!}finkitxmlcodeinlinelatexdvp. Bien sûr, vous allez devoir arrêter de calculer quand le résultat aura atteint la précision requise (nombre k).

Et bien, sachez que ce calcul effectué sur l'unité x87 ne donnera pas un résultat identique au même calcul effectué sur autre unité de calcul flottant. Bien sûr, l'erreur de calcul n'est pas énorme et n'apparaît qu'après une bonne dizaine de décimales, mais elle existe.

Autre problème : rares sont les calculs effectués intégralement dans les registres, et on est parfois obligé de temporairement sauvegarder en mémoire le contenu d'un registre pour laisser le registre libre pour un autre nombre flottant. C'est le programmeur ou le compilateur qui gère quand effectuer ce genre de sauvegarde et sur quels registres. Chacune de ces sauvegardes va arrondir le flottant que l'on souhaite sauvegarder. Conséquence : suivant l'ordre de ces sauvegardes, le moment auquel elles ont lieu et les flottants qui sont choisis pour être sauvegardés, le résultat ne sera pas le même ! Avec le même programme, si vous décidez de sauvegarder un flottant et votre voisin un autre, ce ne sera pas le même flottant qui sera arrondi lors de son transfert en mémoire, et le résultat des calculs sur votre ordinateur sera différent des résultats obtenus sur l'ordinateur de votre voisin.

Pour limiter la casse, il existe une solution : sauvegarder tout résultat d'un calcul sur un flottant directement dans la mémoire RAM. Comme cela, on se retrouve avec des calculs effectués uniquement sur des flottants 32/64 bits ce qui supprime pas mal d'erreurs de calcul.

Il faut savoir qu'il existe plusieurs versions du jeu d'instructions SSE. Une première version est apparue en 1999 sur le processeur Pentium III, qui comportait 70 instructions. Depuis, de nombreuses autres instructions ont été ajoutées aux unités SSE, et chacun de ces rajouts a été accompagné d'un changement de nom du jeu d'instructions, dans un but marketing évident : SSE2, SSE3, SSSE3, SSE4, SSE5…

Il faut remarquer une chose : ces instructions ne travaillent pas toutes avec des nombres flottants et certaines peuvent « instructionner » sur des nombres entiers ! Notre unité SSE n'est donc pas vraiment une FPU au sens propre du terme.

Bien sûr, on retrouve les instructions de base de la norme IEEE 754 pour les calculs flottants, ainsi que de nombreuses autres instructions supplémentaires, non normalisées par la norme IEEE 754. Mais ne comptez pas sur moi pour vous détailler les centaines d'instructions supportées par cette unité de calcul comme on l'a fait pour la FPU x87.

L'unité SSE possède un mode de gestion des dénormaux, activé par défaut, qui consiste à remplacer tous les dénormaux par des zéros, afin de gagner en performances. En effet, les calculs sur les dénormaux sont particulièrement lents et remplacer ceux-ci par des zéros permettra d'améliorer la rapidité des calculs (en diminuant légèrement leur précision). Il va de soi que la norme IEE754 n'est pas censée tolérer ce genre de comportements.

La FPU SSE des processeurs 32 bits contient 8 registres dédiés à cette unité de calcul. Ces registres sont nommés de XMM0 à XMM7. Sur les processeurs 64 bits, on trouve 16 registres numérotés de XMM0 à XMM15. En plus de ces registres de données, un nouveau registre 32 bits de contrôle/statut nommé MXCSR a fait son apparition. Chacun de ces registres peut contenir 128 bits, ce qui leur permet de contenir plusieurs nombres flottants à la fois : 4 flottants simple précision et 2 flottants double précision. Il faut savoir que le jeu d'instructions SSE a été inventé pour que chaque instruction SSE puisse être effectuée sur plusieurs données à la fois. Pour faciliter la conception des unités de calcul SSE, les concepteurs de cette unité ont décidé de placer plusieurs de ces données dans un seul et même registre. Il a donc fallu utiliser des registres assez grands en taille.

Ces registres ne sont pas organisés comme les registres de la FPU x87 et peuvent être lus, sélectionnés et écrits de façon indépendante : il n' y a pas d'ordre de remplissage et une instruction peut agir sur des données venant de n'importe quel registre.

Vu que le jeu d'instructions SSE n'est pas limité aux flottants, mais gère aussi des calculs sur des entiers, ces registres peuvent stocker aussi bien des flottants que des entiers.