Sujet : Re: Compilation ATARI
De : lecoat (at) *nospam* atari.org (Francois LE COAT)
Groupes : fr.comp.sys.atariDate : 27. Sep 2022, 16:45:01
Autres entêtes
Organisation : Aioe.org NNTP Server
Message-ID : <tgv5pu$n99$1@gioia.aioe.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Firefox/60.0
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?
>
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.
En 1986 j'utilisais le LATTICE C avec des disquettes, sur le 1040STf.
C'est mon professeur de mathématiques à Cachan qui m'avait parlé d'une
série de Fourier qui converge très rapidement vers PI/4. Du coup, c'est
le premier programme que j'ai écrit en langage C. Pas printf("Bonjour").
Je l'ai d'abord écrit sur le HP Vectra, puis compilé sur le 1040STf. Ça
m'a définitivement convaincu que j'avais fait le bon choix pour l'ATARI.
Mais à l'époque il n'y avait pas de standard ANSI pour le langage C, ni
de standard IEEE pour les nombres flottants. C'est dans ces conditions
que j'ai commencé à écrire Eurêka 2.12, ça fait maintenant 35 ans.
ATARIstiquement vôtre =)
-- François LE COATAuteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)http://eureka.atari.org/