Lib. pour calcul 64bits ?
-
Admin Dans mon cas : classique et 680O0.
Je suppose que l’origine des Lib. entraîne des faisabilités différentes.
Y a déjà un début ici:
Par décimaux 64 bits, tu veux parler de nombres à virgule fixe en fait?
Les additions sont triviales à partir des additions entières 64bits. La multiplication est à peine plus compliqué. Pour les fonctions trigo, c’est en général les algorithmes “Cordic” qui sont utilisés lesquels se ramènent à des additions et décalages sur les données 64bits.
Google est ton ami pour le détail des calculs “fixed-point”.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)Et bien je suis le premier surpris mais c’est géré pour les décimaux.
Rien à faire de plus que d’utiliser la librairie “math”, vu qu’elle prend en charge le “double” et le “float” avec leurs fonctions respectives, par contre le “%Lf” du “printf” ne prend pas en compte la précision du “double” 🙁
Quant aux entiers 64 bits j’ai rien trouvé.
Mod Est ce que le compilateur C supporte la déclaration long long ?
Ca serait déjà un bon début pour faire de l’arithmétique en entier sur 64 bits.
Si ce n’est pas le cas, il faut passer par la face nord à la force du poignet et attaquer avec un peu d’assembleur.
Il est existe des routines détaillés dans cet ouvrage.
La version classique de GCC, ainsi que SAS/C ne supportent pas le long long.
Pour ma part j’ai codé les algorithmes classics de division/multiplication/addition 64 bits en passant des arguments 64 bits découpés en poids fort et poids faible. On peut abstraire les poids des arguments en utilisant des pointeurs sur des données 64 bits. Question de commodité.
Pour une racine carrée, ce n’est pas plus compliqué que l’algo de division. Quant à la trigo, __sam__ doit pouvoir t’aider. On a déjà disserté là dessus il y a de nombreuses années.
Sinon, il y a une version classique de GCC sous cygwin qui doit théoriquement gérer les long long.
Dans mon cas avec DCC mais pas de 64bits, pour l’instant je pense que les “int64” vont passer en “double” ou perdre 3 digits.
J’ai aussi regardé pour refaire des fct (c’est un travail de recherche sur ces algo. très intéressent) mais à part l’élévation à la puissance, si je peux m’en passer.Peut-être que dans le code 68k de la Vampire on pourrait demander des registres 64bits avec MulX et DivX en dur 😉
Finalement j’ai besoin des fonctions “int64”, déjà pour manipuler et disséquer les “doubles”.
Je suis en train de tester des algo. vites fait et arbitrairement j’ai choisi pour c=f(a,b) :
(E) a=A0 et b=A1 ; adr des deux “int64” à calculer.
(S) c=D0+D1 ; valeur 64bits du résultat.
(de mes souvenirs poussiéreux D0,D1,A0,A1 sont écrasages sur Amiga).
Mais pour faire “respectueux” je me demandais ce qu’il est “propre” de faire sur Amiga pour le passage des param. ; (E) sur pile? ou reg.adresse? et (S) reg.donnée? ou reg.adr? ou pile?
Au final c’est pour utiliser ces fct. Asm dans mon code C.
@tcheko
J’utilise StormC 4 sur classic et il supporte bien (et compile) la déclaration en long long, contrairement à Hisoft C par exemple. Admin A propose de calcul sur des grands nombres, quelqu’un a tenté d’utilise la bignum.library des Ringards avec le Sas/C ou Vbcc ?
J’ai enfin fini les opérations de base sur les entiers 64bits -> 64bits sans perte par dépassement (avec extension le cas échéant) .
Addition et soustraction sont triviales avec le bit de retenue X.
Par contre, le coup des opérations de multiplication et de division me fait un peut peur pour les algo. des fonctions trigo à venir.
Par exemple ma division tourne entre 4564(cas le meilleur) et 11.242 cycles (cas le pire) , algo de décalage et de soustraction (reste-diviseur) et 1600 à 1900 cycles en 32 bits.
La multiplication ~3150 cycles (elle s’appuie sur 4 multiplications 32×32->64 qui elle s’appuie sur 4 multiplications 16×16->32).
Pour utilisation par du code C, quelqu’un pourrait m’expliquer les bonnes pratiques pour passage des param. ? ; ou un lien sur un exemple ?
Mod @counia pour la division, c’est pas trop étonnant comme résultat.
La page wikipedia donne différentes approches pour réaliser celle ci qui je pense devrais être (je l’espère) plus rapide.
https://en.wikipedia.org/wiki/Division_algorithm
Pour les histoires de registres, c’est simple: tu dois préserver les registres que tu trash pendant ton code asm et les restaurer à la sortie minus les registres considérés comme trash.
Les seuls registres non préservés sont bien D0,D1,A0,A1.
De la documentation officielle C= :
System Functions Do Not Preserve D0, D1, A0 and A1.
—————————————————
If you need to preserve D0, D1, A0, or A1 between calls to system
functions, you will have to save and restore these values yourself.
Amiga system functions use these registers as scratch registers and
may write over the values your program left in these registers. The
system functions preserve the values of all other registers. The
result of a system function, if any, is returned in D0.En tout cas, bon courage. 🙂
++
Quelques posts de retards, mais concernant le printf, il me semble que dans la norme (C99) fait que printf ne supporte que les double et cast donc les float en double.
Après ça dépend de l’implémentation qui a été faite sur amiga… !
donc %f prend en charge les double et les float de façon transparente ! (pas besoin de %lf)
Source: http://stackoverflow.com/questions/4264127/correct-format-specifier-for-double-in-printf
Valable au moins sur les environnement qui respectent C99… JE ne sais pas si c’est le cas ici !
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Lib. pour calcul 64bits ?
