Discussion :

[pitistef]

Bonjour à tous,
Je dois actuellement effectuer un petit programme tout simple en assembleur (cible Pentium 2) pour effectuer une multiplication sur un nombre flottant.

Afin de vérifier la représentation des nombres flottants sur celui-ci, j'ai d'abord effectué un bête programme C auquel j'ai défini une variable de type flottant.
J'affecte une valeur à cette variable et vais ensuite voir la façon dont elle est stockée en mémoire.

J'obtiens les résultats suivants:
float_var = 2.8 --> 0x40333333
float_var = 1.4 --> 0x3FB33333
float_var = 1.75 --> 0x3FE00000

J'ai regardé la norme IEEE 754 mais je ne comprends pas du tout la représentation obtenue.
Quelqu'un peut-il me dire s'il voit quelle est la représentation utilisée par mon compilateur C?

[orfix]

C'est bien IEEE 754.
A mon avis la page sur wikipedia est très clair tu pourrais y jeter un oeil !

Convertion de ton premier exemple 2.8 à la main :

1. Le nombre est positif le bit de signe seras donc 0.
2. Convertion en notation binaire 2.8 = 10.1100110011001100110011
   .1100110011001100110011 parceque c'est la somme de :
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   2^-1	*1	0,5
   2^-2	*1	0,250
   2^-3	*0	0,125
   2^-4	*0	0,0625
   2^-5	*1	0,03125
   2^-6	*1	0,015625
   2^-7	*0	0,0078125
   2^-8	*0	0,0039062
   2^-9	*1	0,001953125
   2^-10	*1	0,000976563
   2^-11	*0	0,000488281
   2^-12	*0	0,000244141
   2^-13	*1	0,00012207	
   2^-14	*1	0,000061035
   2^-15	*0	0,000030518
   2^-16	*0	0,000015259
   2^-17	*1	0,00000763
   2^-18	*1	0,000003815
   2^-19	*0	0,000001907
   2^-20	*0	0,000000954
   2^-21	*1	0,000000477
   2^-22	*1	0,000000238
   = 0,799999953

3. Normalisation du nombre binaire obtenu
   10.1100110011001100110011 devient 1.01100110011001100110011 * 2^1
   la fraction est donc : 01100110011001100110011
   
4. L'exposant est 1, il doit être biaisé en ajoutant 127 ce qui donne 128 = 10000000
   
5. En rassemblant le tout on obtient :
   
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
          S EXPONENT FRACTION	
   2.80 : 0 10000000 01100110011001100110011

[ToutEnMasm]

Très bonne explication ,par contre le lien vers wikipedia peut mieux faire.La page existe en français.
http://fr.wikipedia.org/wiki/IEEE_754

[pitistef]

Merci pour vos réponses.
J'avais effectivement lu la page wikipedia mais je n'avais pas compris que l'on utilisait des puissances négatives de 2 pour ce qui est après la virgule.

En gros je convertissais d'abord la partie décimale, puis la partie fractionnelle et complétait avec des 0 pour obtenir les 32 bits. (le système mantisse, signe et exposant je l'avais compris en revanche, c'est déjà ça).

Je comprends donc mieux les résultats obtenus.

[alatox]

J'ai compris les calculs et sait maintenant faire la conversion, mais même en lisant l'article sur Wikipedia, je ne comprends pas pourquoi il doit y avoir un décalage de 128.

Pouvez vous m'expliquer ?

[alatox]

En fait la réponse se trouve dans cette phrase

"L'exposant est décalé de 2^(e-1) - 1 (e représente le nombre de bits de l'exposant). Ce décalage est utile car l'exposant peut être positif ou négatif. Cependant, la représentation habituelle des nombres signés (complément à 2) rendrait la comparaison entre les nombres flottants difficile[réf. souhaitée]. Pour régler ce problème, l'exposant est décalé, afin de le stocker sous forme d'un nombre non signé."

Je comprend que le fait de stocker avec un décalage de 128 permet d'avoir nombres non signés soient positifs ce qui permet de les interpréter tous de la même façon quitte à effectuer un décalage ensuite.

En effet, pour un exposant de -4 par exemple soit 11111100 codé en complément à deux. Ce dernier pourrait être aussi interprété comme 252 par le compilateur.

[Obsidian]

Bonjour,

En fait la réponse se trouve dans cette phrase

En fait, ça, ce n'est pas une explication ! :-) Le « biais » est dû en réalité à un tout petit problème technique.

On souhaite ne pas avoir de zéros non-significatifs à gauche de la mantisse pour éviter de représenter le même nombre de deux manières différentes (du style 5⋅10³ = 50⋅10²). D'abord parce qu'effectivement, cela nous empêche de les comparer bit à bit, et ensuite parce que ça réduit d'autant la variété des nombres qui peuvent être représentés : il n'y a toujours que 32 bits sur un float en SP, ce qui fait que l'on peut y coder au plus 4.294.967.295 nombres différents. Pour ce faire, le premier chiffre doit donc être différent de zéro. Or, en binaire, si un bit n'est pas nul, il vaut forcément 1. Ce bit est donc implicite et n'a pas besoin d'être stocké dans la mantisse. On gagne donc un bit de précision et on empêche de fait toute représentation interdite.

L'ennui, c'est que cette méthode a un gros défaut : on ne peut pas coder le zéro !

Il faut donc choisir une valeur arbitraire pour le représenter. Idéalement, ce serait bien que ce soit « 00 00 00 00 », soit tous les bits à zéro, pour que cela correspondent avec le codage du zéro sur les entiers, et qu'on puisse surtout les repérer avec les détecteurs de zéro des CPU (bit Z des flags). Voyons alors à quel nombre correspondrait cette combinaison : + 1,000000⋅2⁰ = 1. Il est clair qu'on ne peut pas se passer du 1 non plus.

L'ennui vient du fait que « 2⁰ » se trouve en plein milieu de l'intervalle [2⁻¹²⁸;2⁺¹²⁷]. En introduisant le biais en question, on décale toutes ces valeurs de la moitié de l'intervalle et 2⁰ se retrouve tout en bas. « 00 00 00 00 » correspond alors au plus petit nombre positif représentable en simple précision. Les nombres dont l'exposant est plus bas que cela sortent des limites, sont trop proches du zéro et sont donc assimilés à zéro.

Il suffit donc d'ajouter « 00 00 00 00 » à ce dernier cas et de commencer l'intervalle des nombres représentables simplement un pas plus loin, intervalle qui a alors le mérite de rester continu.