Lib. pour calcul 64bits ?

15 sujets de 16 à 30 (sur un total de 31)

__sam__
9 avril 2016 à 14h48 #258946
Dans le cadre de mes investigations sur un format flottant bien adapté aux 8bits, je suis tombé sur un algo super rapide pour calculer log() et exp() en fixed point: http://www.quinapalus.com/efunc.html

Son adaptation 64bits est triviale.

Concernant le mul et le div, il y a moyen de faire très rapide avec des shift+add/sub. Par exemple voici une division 16bits par 16 bits sur un processor motorola 8bits: http://www.logicielsmoto.com/phpBB/viewtopic.php?p=1097#p1097

Pour la multiplication par shift+add, l’algo de Booth est intéressant.

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.)
Counia
10 avril 2016 à 1h00 #258972
@Tcheko
ça confirme sur Amiga ce que j’ai retrouvé ailleurs pour D0,D1,A0 et A1, les autres sont bien sur empilés.

Merci pour les liens, je reviendrais sûr ces algo.

Maintenant ma question est plus sur le passages des param. entre C et ASM.
En C c’est pas mon Pb.
En ASM on connait par définition les registres utilisés.

Mais entre les deux ?
Par exemple comment se ferait en C l’appel de cette routine?
;————————
; Sous Routine Division 32/32 -> 32 et 32 pour le reste:
; (E) A=D0 et B=D1 ; (S) A\B->D0 ,R->D1.
; 1600 à 1900 cycles en 32 bits ; [ Max~900 en 16 ; Max~500 en 8 ].
Divu32R:
link A6,#0 ;Variables locales.
movem.L D2-D3,-(SP) ;Registres supplémentaires.
…
rts

Il fut un temps où j’utilisais cette solution en C:
fonction_Divu32R(int32 A , int32 B , int32 R1 , int R2 )
{
ASM ….;
ASM ….;
…
ASM move.L D0,R1;
ASM move.L D1,R2;
}

Une solution plus élégante (include ou lib) ?
Mod
Tcheko
10 avril 2016 à 9h50 #258989
Quel compilateur ?

Sinon, le plus ‘simple’ est tout simplement de faire une vraie bibliothèque système et générer les pragmas à partir du .fd qui vont bien pour ‘hinter’ le linker pour les registres à utiliser.

Exemple de bibliothèque

Un tutorial pour créer une bibliothèque

Ha. Dernier point qui peut dérouter au début : si on veut modifier la bibliothèque, il est nécessaire de la sortir de la mémoire avant de relancer son code de test. En effet, même si aucun programme utilise la bibliothèque, elle restera chargée en mémoire tant qu’il y a suffisamment de mémoire libre. Au premier échec d’allocation mémoire, Exec tentera de libérer des ressources en appelant la fonction Expunge de toutes les bibliothèques.

Donc, en phase de développement, il suffit d’ajouter une allocation mémoire dont on est sur de l’échec avant d’ouvrir la bibliothèque à tester. Naturellement, le système va retirer la bibliothèque de la mémoire et la nouvelle version sise sur le disque sera à son tour chargée.
Counia
11 avril 2016 à 12h43 #259095
Je compile avec DCC.

Merci Tcheko mais ça me parait bien compliqué à mon niveau, j’y reviendrais peut-être plus tard quand le reste sera digéré, plus j’avance plus de problématiques s’ouvrent et j’ai peur de trop me disperser.

Après avoir gratter quelques info., je cherche plus simplement à faire un « include » de mon code ASM.
DCC peut passer les param. par les registres, mais par défaut ce serait dans la pile, empiler du dernier au premier, ça roule donc pour les fct « void » ; par contre rien lu sur le fameux « return r; il serait le 1er param.? le dernier? dans un registre ? »

Je modifie donc mes fonctions 64bits en ASM pour coller à cette info.

Je porte mon code ASM sous « Devpac3.18 » que je ne connais pas, à partir de là sauriez vous m’orienter pour en tirer les fichiers « .o », « .i » et « .h » ?
Counia
15 avril 2016 à 2h54 #259377
Je me répond à moi même, ça pourra en aider d’autre à moins galérer 😉
Sous Devpac, perso j’œuvre en ligne de commande et la génération du « .o » ce fait ainsi: « GenAm Fich_ASM.s -L3 ».
On a alors un joli fichier « Fich_ASM.o »
REM: ne pas oublier les lignes XDEF NomFct dans le code ASM ; j’ai galéré un bon moment avant de tomber sur un exemple en code 8086 (merci les PC).
Pour les « .i » je fais l’impasse et je ponds direct un « .h » tel que je l’attend dans mon code C.
Ensuite « DCC Fich_C.c Fich_ASM.o -o MonExe »
Au passage, contrairement à ce que j’ai pu lire, les param. sont bien passés dans l’ordre de déclaration (de gauche à droite donc).

cqfd, y a plus qu’a avancer sur les fonctions des int64.
Counia
23 avril 2016 à 17h50 #259893
J’ai un peut avancé !

Par-contre je voudrais pour certaines variables « redondantes », plutôt que de les passer en paramètres (C vers ASM) à chaque fois, les définir dans le code ASM et les référencer dans le C ou plutôt dans le .H en externe.

Concrètement: (des 64bits utilisés par mon code)
Extension ds.l 2
Resultat ds.l 2
Reste ds.l 2
ou cet espace Mém utilisé pour conversion de mes 64bits en BCD:
TabBCD dcb.b 10,$00

J’ai tenté en « XDEF _Toto » dans mon code ASM.
Mais comme je ne suis visiblement pas bon dans les « typages », mon compilateur râles.

Faute de mieux, pour l’instant, ces 64bits sont définis coté C et passés en param. comme une adresse de « struct{ int int} » pour faire les 64bits.
Bien que ça marche, ce n’est pas ce que je voudrais et de plus il me semble que rien ne garantie que les champs de la « struct » soient contiguës en mémoire.

Si vous savez m’aider là dessus ?
Mod
Tcheko
23 avril 2016 à 20h53 #259900
Je n’ai pas la documentation de DCC mais pour d’autres compilateurs, tu as la directive ‘pragma pack’ qui permet d’ajuster les alignements dans les structures.
Mais dans ton cas, avec deux long sur 32 bits, il n’y aucune raison pour que le compilateur les place de ‘travers’. Les deux long seront donc bien l’un derrière l’autre.

https://en.wikipedia.org/wiki/Data_structure_alignment
__sam__
24 avril 2016 à 0h04 #259903
pour les zones mémoires contigues, penser aux tableaux!

typedef int montype64[2];

extern montype64 Toto; // sera liè à un XDEF _Toto en ASM

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.)
Counia
25 avril 2016 à 23h13 #260006
J’ai pensé aux tableaux pour le BCD mais ce ne m’était pas venu à l’esprit pour le 64bits. Plutôt que de m’engluer dans ma stuct, un pointeur de int ça me va bien.
Bonne idée merci à vous.
Counia
25 avril 2016 à 23h26 #260007
@Tcheco effectivement je n’est pas de pb avec ce passage C vers ASM, j’avais un doute sur la continuité en mémoire.
C’est lorsque j’en définis coté ASM que je cafouille à les déclarer dans le C (manque de rigueur de ma part).
Counia
26 avril 2016 à 1h25 #260010
Retour à chaud:

struct{int int} ou int[2]
Pour moi, fonctionnement identique ; si tableau mon compilateur apprécie que je ne précédé pas du & (soit, je le contrarie pas).

Par contre dès que j’utilise une variable du code ASM ça passe pas.
Je dois faire une bourde tellement évidente que je la vois pas.

Concrètement mon 64bits en int[2] dans le « .H » (du __SAM__ direct):
typedef int Nbr64[2];
extern Nbr64 Extension;

« .S »
XDEF _Extension
Extension: ds.l 2

« .C » ici test sur la multiplication A*B -> C avec D ou Extension b127 à b64.
Nbr64 A,B,C,D;
Mulu64(A,B,C,D); /* compile Ok */
Mulu64(A,B,C,Extension); /* compile KO */
>illegal A4-ref to far object: _Extension…
Counia
28 avril 2016 à 3h13 #260129
Trouvé! , le compilateur adresse les variables par référence, comme cette variable est externe, on ne doit pas être dans la plage de décalage.
En forçant l’adressage absolu (__far) ça passe et ça marche.
Counia
8 mai 2016 à 20h07 #260628
Bonjour,
Question sur les nombres à virgule:
je suis sur un format flottant 64bits (1+11+52) mais je pense que la question reste valable sur tout codage fractionnaire.
Quel algo. est utilisé pour transcrire cette partie fractionnaire, vers une interface humaine ? (ex:utilisation dans printf)
Et inversement, quel algo. détermine le codage du nombre (surtout partie fractionnaire) à partir d’une écriture ASCII ou BCD ? (ex: saisies / pré-compilateur: i=3.1415;).
Je précise que je vois très bien le codage et le fonctionnement par somme des fractions de puissance de deux, je cherche si il existe un algorithme optimisé de passage entre ces deux formes d’écriture.
Si vous avez des pistes, merci ?
Counia
24 mai 2016 à 20h14 #261362
Autre question (moins algorithmique).
L’appel de mes fonctions se fera à partir d’un code C.
Y a t’il un moyen en C de sortir de la notation préfixe pour mes fonctions.
Par exemple sur une multiplication:
Mulu64( Var1 , Var2 , Var3 ); /* ici Var3 <- Var1 x Var2 */
En utilisation:
Var3 = Var1 Mulu64 Var2;
Var3 = Var1 * Var2;
__sam__
25 mai 2016 à 1h45 #261374
Une implémentation complète des routines IEEE 64bits en C est dispo dans la fdlibm[/url] (ftp://ftp.netlib.org/fdlibm.tar)

Pour le printf d’un format flottant, j’avais trouvé ceci: http://stackoverflow.com/questions/2302969/how-to-implement-char-ftoafloat-num-without-sprintf-library-function-i

Je l’ai utilisé en java avec un type FP à moi (float avec mantisse sur 16bits initialement mais tunable pour avoir plus ou moins). Dans toString() tu trouvera la routine de conversion en ascii (printf), et dans le constructeur FP(String s_) tu trouvera le parsing (ascii->FP).

A noter: c’est du code java, mais ca devrait être compréhensible car très proche du C. Concernant la syntaxe en C vu es vite pas mal pénalisé: tu dois ecrire plus(x,y) et pas x.plus(y) comme en java ou x + y avec la surcharge des opérateurs de base en C++.
Attachments:

FP.txt
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.)