Discussion :

[ytfin]

Bonjour à tous,

En dépit de mes recherches, je n'ai pas trouvé de solution concernant le problème suivant,
rencontré lors de l'exécution d'un programme effectuant des calculs en virgule flottante.

Assembleur utilisé : GNU/Gas (syntaxe AT&T) en 64 bits.

Commande de compilation : as -g --64 float_c.s -o float_c.o
Commande de link : ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 float_c.o -o float_c -lc

Je ne parviens pas à transférer dans le registre FPU %st(0) le contenu complet et exact (nombre entier) d'une adresse mémoire ("variable") déclarée ainsi :

.lcomm RESUL, 8 (soit 8 octets ou 64 bits)

Il apparaît que le nombre reçu est limité (?) à 32 bits. Les calculs en virgule flottante
subséquents se trouvent par conséquent totalement erronés.

A titre d'exemple voici des extraits de la session de débugging sous GDB correspondant au
sous-programme "flottant_c" :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
~/Developpement/Asm/Src/Gas/tests$ gdb ./float_c
 
Reading symbols from ./float_c...done.
 
(gdb) b flottant_c
Breakpoint 1 at 0x400483: file flottant_c.s, line 13.
(gdb) r
 
Starting program: /Developpement/Asm/Src/Gas/tests/float_c 
 
Nombre réel saisi : 3.1415926535
 
Breakpoint 1, flottant_c () at flottant_c.s:13
13 pushq      %rbp		 # sauvegarde %rbp			    
(gdb) b 19
 
Breakpoint 2 at 0x400495: file flottant_c.s, line 19.
(gdb) c
 
Continuing.
 
Breakpoint 2, traitement_calculs () at flottant_c.s:19
19 movq	      %rbx	 , RESUL      # %rbx = réel saisi converti préalablement en nombre entier	
(gdb) s
 
(gdb) p $rbx
$1 = 31415926535
(gdb) p RESUL
$2 = 1351155463
(gdb) p/u RESUL
$3 = 1351155463
 
(gdb) s
24 fildl       RESUL		    # st(0) = RESUL (différent du nombre entier de %rbx)	
(gdb) s
 
(gdb) p $st0
$4 = 1351155463
 
(gdb) c
Continuing.
 
Opérande de multiplication & division : 2.30
Division du nombre réel               : 0.0587458897
Multiplication du nombre réel         : 0.3107657565
 
[Inferior 1 (process 3656) exited with code 01]
(gdb) q
 
~/Developpement/Asm/Src/Gas/tests$

Les trois résultats sont affichés in fine à l'aide de la fonction C "printf" (seule fonction externe à l'assembleur appelée par le programme).

Je me résous à faire appel à vos connaissances pour trouver une solution à ce problème.

Avec mes remerciements. Cordialement.

[ytfin]

Bonjour à tous,

En complément de mon message précédent, et poursuivant mes recherches, vaines jusqu'à présent, j'ai effectué de nouveaux tests à partir de deux programmes simplifiés intégrant les instructions FPU 64 bits.

Ecrits avec deux syntaxes assembleur différentes, disponibles sous Linux : Intel (compilateur Nasm) et AT&T (gas), ils permettent de comparer les résultats obtenus pour chacune.

1°) Compilation en syntaxe Intel :
nasm -g -f elf64 flt_64.asm -l flt_64.lst
gcc -m64 flt_64.o -o flt_64

2°) Compilation en syntaxe AT&T :
as -g --64 flt_64a.s -o flt_64a.o
ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 flt_64a.o -o flt_64a -lc

Les données, codées en "dur", sont identiques à celles mentionnées dans mon message d'origine.
Nombre entier support (variable 'i') : 31415926535
Multiplicateur (variable 'x') : 2.3
Résultat (produit a = i * x)

Résultats obtenus :
1°) Version nasm : ./flt_64
Produit a = i*x : 72256631030.50000 <- résultat conforme

2°) Version gas : ./flt_64a
Produit a = i*x : 3107657500.47189 <- résultat erroné

A noter que dans le cas où le nombre entier support est égal ou inférieur à 314159265, les
résultats sont corrects dans les deux versions.

Il se confirmerait que le problème se situe bien à l'égard de la variable entière de 64 bits,
non supportée intégralement sous GNU/Gas...

Une explication ?

Avec mes remerciements. Cordialement.

[ytfin]

Bonjour à tous,

Solution mise en œuvre :

Dans la version syntaxe AT&T, l'instruction FPU x87 'fild' doit être suffixée avec la lettre 'q'.
Par contre, la syntaxe Nasm ne l'admet pas.

Voilà.