Sujet : Re: Compilation ATARI
De : moulinaie (at) *nospam* gmail.com (Arachide)
Groupes : fr.comp.sys.atariDate : 27. Sep 2022, 09:39:09
Autres entêtes
Message-ID : <d26765aa-8523-49ee-92c0-25e16d214f4an@googlegroups.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
User-Agent : G2/1.0
Le lundi 26 septembre 2022 à 23:23:38 UTC+2, Francois LE COAT a écrit :
Salut,
Arachide écrit :
64bits. Je parle du format "double" qui diffère, il me semble, sur
80 ou 96bits. Il suffit de programmer "printf("%d\n", sizeof(double))"..
Et ça donne quoi?
Guillaume.
Les coprocesseurs mathématiques étaient très peu répandus en 1986.
Ça dépend du compilateur C. En 1986 je programmais Kernighan & Ritchie,
sur des compilateurs qui étaient tous différents, puisque la norme IEEE
pour les nombres flottants date de 1985. Les éléments qui ont permis
d'obtenir le résultat n'existent plus. Je ne peux pas te répondre ...
Ce qui est à peu près sûr, c'est que les formats "double" étaient très
différents d'un compilateur C à un autre, à l'époque.
J'ai regardé de plus près, les deux systèmes (Intel/Motorola) proposent des formats courts (32 bits), double (64 bits) et Extended (80 bits) pour les réel. Le 96 bits est un format BCD permettant les conversions rapides vers l'ASCII.
Avec Pure C, je trouve qu'ils ont raté un truc! Leur format Double ou Long Double est identique: le 80 bits. Donc Pure C n'utilise jamais la version 64 bits des réels, ce qui est dommage! Le programmeur peut décider normalement de la précision qu'il souhaite...
Et travailler en 80 bits alourdit le code:
- déplacer 10 octets ne se fait pas en une seule instruction (à moins d'utiliser un movem sur des WORDS et de cramer 5 registres...)
- alors que 64 bits, c'est un movem.l avec deux registres seulement.
- 10 octets dans des tableaux, c'est perdre l'alignement sur 16
- accéder à un élément d'un tableau de doubles se fait en une seule instruction assembleur sur 68030 lorsqu'on n'a pas de FPU
A0 pointe sur la base du tableau
D0 est l'index de l'élément 64 bits souhaité
movem.l 0(A0,D0.L*8),d1-d2
charge dans D1 et D2 les 64 bits du réel double.
Alors qu'avec 10 octets, on est obligé de modifier l'index (ou d'utiliser un autre registre):
muls #10,d0
movem.l 0(A0,D0.l),D1-D2
ça ajoute une multiplication et ça modifie D0 et ça perd l'alignement sur 16...
Bien sûr, avec le FPU, on utilise des FMOVE ou FMOVEM pour déplacer/copier des réels à la taille désirée.
Bien des logiciels en virgule flottante se seraient bien contentés de 64 bits de précision, mais compilé avec Pure C, c'est impossible. (A moins qu'il n'y ait eu une librairie autre que la standard)
Guillaume.