FLOAT EN HEXA (WIN32, ASM)
NitRic
Messages postés
402
Date d'inscription
mardi 1 mai 2001
Statut
Membre
Dernière intervention
15 août 2011
-
19 janv. 2007 à 05:07
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 27 mai 2008 à 19:19
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 27 mai 2008 à 19:19
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/41170-float-en-hexa-win32-asm
https://codes-sources.commentcamarche.net/source/41170-float-en-hexa-win32-asm
27 mai 2008 à 19:19
Ce n'est pas un "abandon" pour l'IA64 (Itanium), simplement que l'architecture est radicalement différente du x86. SSE est par contre bien présent en mode x64 et c'est même ainsi qu'on l'exploite au mieux.
En ce qui concerne cet "abandon", regarde ici:
http://www.silicon.fr/fr/news/2008/05/26/serveurs_hp_devance_ibm
2,27 millions de serveurs x86 vendus au 1er trimsetre 2008 rien que pour HP. Faudrait plutot parler du quasi abandon du IA64.
SSE est en très bonne santé et installé pour un bon bout de temps.
22 mai 2008 à 16:06
Note: je n'ai fait aucune attaque contre les auteurs mentionnés ici dans mon message initial et je ne vois pas pourquoi on m'a ensuite répondu vertement. Mon commentaire était franchement gentil et n'avait rien à voir avec un "archarnement". Il était même plus sympatique que les autres commentaires postés par d'autres avant moi.
Cependant je critiquais directement une "solution" proposée qui consiste à remplacer une copie mémoire par une affectation simple: cela ne marche pas avec la précision native des flottants sur 80 bits (voire plus). Le SSE n'est pas non plus un modèle excellent en terme de précision des calculs, il vaut mieux le savoir: le SSE n'est PAS conforme IEEE, et la précision varie même d'un modèle de processeur à l'autre!
Je laisse aussi de côté le fait que SSE n'est pas une plateforme stable (déjà abandonnée en 64bits): nombre de registres indéfini, design assez mal fichu des instructions. Au vu de la durée de vie demandée au logiciel, c'est déjà une mauvaise solution de l'utiliser sans prévoir dès le début une solution de repli en cas d'absence.
Enfin l'utilité du SSE pour convertir des chaines isolées en nombres ou l'inverse me dépasse! Ce n'est pas là qu'un logiciel perd du temp, s'il y a des goulots d'étranglement à résoudre c'est bien ailleurs: les boucles de traitement de signal, les calculs complexes, etc...
Qui effectue des conversions de format dans des boucles de calcul massif ,sachant les problèmes de perte de précision que ce genre de conversion implique, ainsi que l'inefficacité totale des formats chaine pour effectuer des calculs ou transmettre des valeurs et résultats? Les chaines c'est pour les entrées-sorties et ce n'est pas le format utilisé sans les entrées-sortie qui étranglent les performance mais bien l'opération d'I/O elle-même (où de toute façon le processeur n'a rien d'autre à faire qu'à attendre ou passer la main à un autre thread: les différents jeux d'instructions SSE, SSE2, MMX, 3DNow!, etc... sont couteux pour les performances en multithreading car ils allongent le temps de commutation et augmente les ressources nécessaires pour que la commutation se passe correctement d'un thread à l'autre; leur support même par les constructeuurs ne dépasse guère 5 ans: le temps de développer le logiciel avec, ils sont déjà obsolètes avant même d'avoir été utilisés).
22 mai 2008 à 12:37
Bon je dis ca je dis rien, mais tu n'installeras pas Adobe CS3 si tu n'as pas un cpu gerant le jeu d'instructions SSE2.
Peut etre que dans ton domaine la portabilité est d'une importance capitale, mais dans bien des cas, elle n'est qu'un freins aux performances!
Je trouve ca bizarre que tu t'obstine avec de tels arguments! Donc pour toi les instructions SSE2 &co sont la juste pour garnir et ne doivent pas etre utilisees ?
Puis une autre chose, rien n'empeche si besoin est de fournir des routines "generique" en plus et de faire if (!instrunctions_specific) then loadLibrary(generic_routine.dll) else LoadLib(sse2lib.dll)
Que dire des cpu multicore ? doit on ne pas faire de prog otpimises pour les multi sous pretexte que beaucoup de personnes tournent encore en mono core ?
A ce rithme la je ressorts mon commodore moi!
++
20 mai 2008 à 19:54
Dans tout autre domaine professionnel on voit des spécialités. Il n'y a qu'en informatique qu'on trouve pareil sectarisme, que soit pour l'OS ou le codage.
20 mai 2008 à 16:19
Il est aujourd'hui très clair que ce n'est pas le choix du matériel qui importe mais le cout de développement du logiciel. Faire une optimisation pour un modèlespécifique de processeur qui ne sera supporté même pas pendant un an par son constructeur, alors que d'ici là le client continuera à faire évoluer son parc logiciel et matériel de sorte qu'il se retrouvera FORCEMENT avec un parc hétérogène alors que son logiciel spécifique n'aura pas encore été rentabilisé, et les petites optimisations dépassées rapidement par les évolutions du matériel (dont le coût d'acquisition lui ne monte jamais mais n'arrêt pas de baisser alors que les performances montent), c'est jeter de l'argent par les fenêtres. Réellement.
Il y a de la place pour des optimisations, mais les plus utiles ne sont pas tant celles au plan du micro-code, mais celles en terme de design et d'algorithmique, c'est à dire celles qui dépendent d'un ordre de complexité (souvent polynomial ou exponentiel), et non une petite réduction linéaire (le gain obtenu, avec beaucoup d'effort tant en terme de développement initial que de remplacement du logiciel, est obtenu sans aucun effort par la simple évolution du matériel).
Dans ton "équation" justifiant un tel code tu oublies totalement la complexité et le coût en terme de remplacement du logiciel, coût de maintenance (et tu oublies que tu auras aussi un successeur, de ta preopre boîte, ou d'un fourniseur concurrent, ou de ton client lui-même qui exigera du code clair et maintenable ou refuseras de payer intégralement pour sa recette...)
Je suis désolé pour toi mais tous les clients et toutes les sociétés pour lesquelles j'ai travaillées ont exigé du code portable capable d'évoluer avec le reste du parc matériel et logiciel. Les cas où on travaille sur un parc totalement homogène sont réellement l'exception, même quand on programme du logiciel embarqué (firmware, etc.) car même dans ce cas on réduit le coût de développement en réutilisant le code.
Ces cas exceptionnels incluent les développements à caractère strictement personnel quand on est maître à la fois de son temps, de son argent, et de ses propres choix logiciels et matériels. Mais même quand on travaille pour un client unique qui maîtrise tous ses choix, il évitera de payer un code dont il ne pourra plus ensuite modifier une seule ligne (où la tentative de réutilisation de ce code spécifique risque de lui coûter plus cher que le développement initial...).
En fait il est même très difficile de maitriser soi-même tous les choix techniques (sinon même leur cout d'acquisition unitaire devient prohibitif) car la plupart des solutions sont packagées et résultent de différents compromis (dont celui du rapport prix/performance et celui du cout d'intégration). Et dans ce cas la question de la portabilité ne se pose même pas pour les évolutions futures (et très probables) du parc informatique, mais bien dès le départ souvent aussi car les choix techniques initiaux ne sont même pas connus avec précision. La portabilité et l'évolutivité sont des critères déterminants dès le début du cycle du vie du logiciel, et cela lui donne aussi plus de valeur intrinsèque, à court comme à long terme.
20 mai 2008 à 12:22
20 févr. 2007 à 20:00
Je pense que BruNews et ses clients se mettent d'accord sur les spécifications du logiciel à développer dès le début. Donc, si le client veut "un logiciel optimisé pour un parc précis" alors, je ne vois pas le problème lorsque Brunews fait en poussant l'optimisation le plus loin.
Est-ce que c'est la peur que le client change d'avis? euh,...faudra demander à Bru si ces clients leur arrivent de changer d'avis :)
19 févr. 2007 à 00:30
http://www.cppfrance.com/code.aspx?ID=41536
18 févr. 2007 à 19:55
18 févr. 2007 à 19:49
Les parcs hétérogènes de machines sont une réalité rencontrée par pratiquement tout le monde, sauf quand on développe un système embarqué totalement autonome (mais ce genre de développement embarqué ne se fait pas en programmeur isolé mais dans un équipe avec d'autres moyens, et presque toujours aussi un chier des charges serré au niveau temps, et encore plus serré au niveau de la qualité du logiciel et du design). Sinon c'est du développement gratuit (universitaire, travail d'étudiant...), ou un travail de passionné (pour son propre usage, et on n'en a rien à faire de ce que demandent les autres) ce que je respecte car c'est formateur (mais pas forcément un exemple à suivre pour les autres).
18 févr. 2007 à 19:34
Je prépare un petit exemple, je vais mettre 2 boutons pour lancer le code SSE2 ou celui en C que tu pourras arranger comme il te plaira, on verra ensuite le résultat.
18 févr. 2007 à 19:01
18 févr. 2007 à 18:59
: Cela fait maintenant des années que je ne m'intéresse plus guère aux optimisations de bas niveau, les auteurs de compilateurs ou de librairies open-source font ça beaucoup mieux que moi, et c'est plus économique de réutiliser leurs solutions que de réinventer la roue à ce niveau.
: En fait, avant de faire n'importe quelle optimisation, on devrait toujours commencer par faire un profilage de l'application pour savoir où sont vraiment les points critiques. La règle est que si la partie qu'on voulait optimiser représente moins de 10% de charge CPU, cela ne sert à rien de passer du temps à l'optimiser: le temps qu'on fasse ça, les technologies évoluent plus vite et ont gagné le supplément de performance requis.
: C'est encore plus vrai quand on est développeur indépendant car on ne peut pas perdre du temp là dessus au détriment des fonctionnalités et du design général: notre temps est limité, et ce n'est pas rentable, on a deschoses plus intéressantes à faire.
: Bref, un bon développeur indépendant passera du temp à rechercher et comparer les meilleures librairies, participera éventuellement à leur amélioration sur un point particulier, mais a tout intéret à réutiliser le code fait par d'autres. ~~~~
18 févr. 2007 à 11:24
18 févr. 2007 à 09:52
si un client lambda demande un moteur de calcul pour une (grosse) machine particulière, ou pour un gros cheptel de machines, on fait avec...
on fait pas nécessairement portable "au cas où", eclipsant volontairement les atouts du processeur ciblé... le client en question, sinon, aurait pris un poste générique, et tout serait ok.
18 févr. 2007 à 03:31
C'est aussi l'occasion alors de recevoir des demandes d'améliorations (et non des fiches de bogues ou des annulations de contrats!) pour ajouter la fonctionnalité manquante (support d'une autre plateforme). Il y a énormément de sociétés qui IMPOSENT de fournir ces règles d'interopérabilité, et de S'ENGAGER soi-même sur les fonctionalités supportées, faut de quoi le logiciel ne sera même pas évalué et rejeté immédiatement en bloc, car elles ne seront même pas elles-mêmes en mesure de savoir comment réutiliser ce logiciel dans leurs propres offres et de s'engager elles-mêmes sans prendre des risques conséquents (qui peuvent être très couteux). C'est aussi une exigence du consommateur lambda qui s'attend à ce que le logiciel fonctionne sur la plateforme décrite. C'est enfin une exigence de bonne intelligence pour ne pas se priver soi-même d'un marché potentiel (et cela reste vrai même en open-source gratuit, fain que l'utilisateur sache ce qu'il doit éventuellement changer dans sa plateforme et évaluer les couts avant de décider d'utiliser un logiciel!).
17 févr. 2007 à 12:58
Pour les perfs c'est idem, SSE2 atomise les temps d'un pauvre code C sans l'ombre d'une hésitation.
16 févr. 2007 à 19:27
Donc à moins qu'on fasse un logiciel embarqué (et dans ce cas on travaille avec des outils spécifiques et avec souvent des connaissances bien plus pointues sur le sujet où il est absolument indispensable de circonscrire totalement les dépendances techniques selon un plan de design, et cela se fait pour des projets bien encadrés en milieu fermé), je ne comprend pas ton commentaire.
Pour moi, la catégorie des logiciels non portables appartient à celle des logiciels jetables rapidement. Ils cessent de fonctionner rapidement au delà de quelques cas isolés d'utilisation, et aucun support n'est prévu en cas d'évolution (il faut rappeler que les technologies utilisées ne cessent d'évoluer, et dépendre d'une seule qui cesse d'être supportée ou d'être disponible est un pari risqué...) Donc écrire un logiciel non portable est toujours un risque. On obtient très vite quelquechose qui marche, et on a très vite quelquechose qui ne marche plus non plus!
J'ai vu nobre de codes sensés être optimisés pour le jeu d'instrution MMX ou SSE d'un processeur particulier et qui en fait est BIEN PLUS LENT que le même logiciel générique tournant sur un processeur supportant ces jeux étendus. La faute en revient non pas à l'optimisation spécifique d'une partie du code, mais à la conception générale de tout le reste. Le plus souvent, je trouve totalement inutile de passer autant de temps à optimiser une partie infime du code si pendant ce temps là on sacrifie la qualité de tout le reste du logiciel. Ce genre d'optimisation n'est utile que ponctuellement à condition d'avoir un code générique stabilisé et toujours employable. Bien souvent, il faut des compétences bien plus avancées que la simple connaissance du jeu d'instruction SSE pour en tirer pleinement partie.
Je trouve qu'on perd trop de temps à optimiser ça pour une partie spécifique d'un logiciel, et qu'on ferait mieux de collaborer à la mise en oeuvre de ces techniques dans un compilateur. C'est pour ça qu'on obtient de nombreux programmes bourrés d'optimisations supposées écrits en C/C++ voire ave de l'assembleur qui sont en fait bien plus lents que le même programme écrit en Java: l'optimisation est en fait bien mieux faite (et a un effet global sur toute l'application) au sein du compilateur natif intégré à la machiune virtuelle, qui reste: portable, limitée en taille, offre moins de possibilités de bogues, et facilement déployable.
C'est une question de logique: on sépare le développement en plusieurs niveaux par isolation des APIs et dépendances. C'est la base même du développement moderne, avec des objets ou composants bien isolés, optimisables séparément, et remplaçables séparément selon des spécifications définies en amont. C'est le "Design by Contract" qui permet une réutilisation facile du code, et sa maintenance par les meilleurs programmeurs dans chaque domaine de compétence. L'important n'est plus comment on fait quelquechose, mais ce qu'on est sensé faire. La façon de le faire dans un composant particulier est secondaire et non nécessaire au projet tout entier.
16 févr. 2007 à 09:49
Le prix du serveur représantant un infime pourcentage du calculateur, tout ce discours n'est plus que de la philo.
Doit-on fermer Polytechnique parce qu'elle n'est pas accessible au pékin moyen ? ben que nenni, réduire tout au plus petit commun dénominateur n'est pas dans ma façon de penser et mon carnet de commandes me dit de continuer ainsi.
16 févr. 2007 à 03:43
Certains "conseillent" d'optimiser Windows en augmentant la taille du cache L2 qu'il va utiliser. Hors si vous mettez la valeur maximale égale à la taile indiquée par les spoécifications théoriques du processeur, Windows va planter instantanément au boot. Pourquoi? Parce que des parties du cache sont devenues désactivées (et cela concerne pratiquement tous les processeurs actuels!)
Les optimisations qui q'appuie trop sur le comportement théorique des pipelines vont aussi échouer très souvent, car ce comportement théorique est contredit par le comportement effectif adopté par le processseur après son autotest. Il y a des outils pour regarder la configuration actuelle du processeur, mais cela n'est utilisable qu'au boot, avant que le code entre en mode protégé. Après, ces registres internes restent parfois accessibles en lecture seule (pas toujours) et uniquement par le kernel (ring 0) par exemple dans le pilote installé sur l'OS pour le processeur, mais pas par les applications. N'essayez pas d'y toucher pour tenter de l'optimiser. Il y a de grandes chances pour que vous plantiez tout. Les autotests sont prévus pour fournir un comportement raisonnable et exploitable sur une longue durée. On n'est plus au temps où les processeurs avaient un comportement encore prédictif d'après leurs spécifications. Ce temps est fini depuis le processeur Intel 80386 et le Motorola 64040 (et tous les modèles ultérieurs y compris des autres marques), et les spéifs actuelles donnent très souvent des fourchettes de temps ou des nombres moyens de cycles pour bon nombre d'opérations (d'ailleur pour préserver leurs secrets de fabrication, les opérations en virgule flottante les plus complexes ne sont jamais décrites avec le temps exact de ces opérations, ni la totalité des critères requis pour obtenir ces temps qui sont parfois obtenus uniquement en utilisant les librairies propriétaires de calcul vendues fort chères, sans les sources, par les fabriquants de processeurs et utilisés dans leurs benchmarks privés).
Aujourd'hui un bon processeur est inséparable de son pilote pour l'OS vers lequel il a été conçu et optimisé, et il vaut mieux ne pas trop toucher au comportement de l'OS car le processeur n'aura pas un fonctionnement garanti. Ceux qui ont fait de l'overclocking de leurs processeurs pour tenter de battre des records de vitesse dans les projets de calcul distribués (SETI@home par exemple) se sont vite rendus compte que les résultats de calul obtenus étaient tout bonnement faux et ont perdu leurs scores, quand il n'ont pas tout bonnement grillé complètement leur processseur ou totalement le FPU qu'il contenait, de sorte que l'OS ne supporte plus que l'émulation logicielle!
16 févr. 2007 à 03:27
Il y a aussi des différences dans les résultats intermédiaires des expressions: le FPU peut utiliser des flottants dénormalisés pour gagner du temps, mais le stockage dans une variable renormalise le résultat.
Si vous ne savez pas ce qu'est un flottant normalisé, regardez les spécifications de l'IEEE.
Préparez vous aussi à lire les différents formats pour coder 0 (avec ou sans signe!), l'infini, les valeurs "NaN", les valeurs spéciales codant certaines autres exceptions (pour lequelles le résultat est parfois encore utilisable pour évaluer le reste des expressions).
Faites attention aussi aux valeurs proches de 0 dénormalisées, qui deviennent "égales" à 0 une fois normalisées.
Enfin prenez garde aux modes d'arrondis, c'est plus compliqué que ça en a l'air (l'arrondi au pair le plus proche est une chose souvent mal comprise), et une librairie en asssembleur omet parfois de préciser qu'elle a modifié unilatéralement le mode d'arrondi (dans un registre spéial du coprocesseur).
L'IEEE recommande le mode d'arrondi au pair le plus proche pour toutes les applications en langage évolué, quelle que soit la précision du résultat (32, 64 ou 80 bits), et un compilateur C devrait s'assurer, avant de faire un appel externe à un code assembleur, que ce mode est restauré, à moins que le C-runtime fournisse une API fiable permettant de fixer ce mode et de le mémoriser de façon fiable. Attention: de nomnbreuses librairies oublient souvent de prendre en compte cette préférence, et forcent leur calcul dans le mode recommandé par l'IEEE, et ne restore pas le mode initial voulu par le programmeur).
Les normes IEEE sont référencées par les normes de langages C, C++, Java, C#, ADA, ... Elles ont normalement un caractère normatif dans ces langages, mais de nombreuses implémentation font l'impasse dessus, ce qui conduit à des différences de résultats entre systèmes différents, voire même d'un PC à l'autre (en fonction du modèle exact de processeur utilisé!).
Il n'y a guère que Java et ADA qui fassent un contrôle strict du modèle de calul IEEE et assure une portabilité totale du calcul avec une précision garantie (les machines virtuelles CLR pour .Net n'assurent pas ce contrôle, ni presque aucune librairie C/C++ standard!)
Quand au code utilisant les instructions MMX, SSE, et autres 3DNow! difficile de faire moins portable, d'autant qu'il y a de nombreuses variantes! Programmer ça soi-même requière une connaissance excellente de tous les modèles, et c'est plutôt ) éviter: on utilisera plutôt des librairies qui ont été portées sur haque processeur de façon fiable pour avoir une API de calcul utilisant le parallélisme si possible.
En pratique, on utilise des librairies de traitement spécialisées (telles que DirectX ou OpenGL) qui définissent une sémantique pour le traitement parallèle, ce qui permet une implémentation efficace adaptée à chaque processeur: c'est une bonne pratique car cela sépare le code applicatif du code optimisé dépendant du matériel, dont il existe beaucoup trop de stratégies d'optimisation adaptée à chaque cas.
Pour le calcul de précision, le C ou C++ est un très mauvais langage de ce point de vue, car rien n'y est vraiment prévu pour bénéficier du parallélisme et des accélérations matérielles possibles, sans créer immédiatement du code non portable ou même carrément inefficace et très lent voire complètement faux sur une autre machine alors même que c'est le même programme compilé tournant sur le même OS.
Les librairies standards C/C++ du runtime de Microsoft sont faites pour être très portables d'un processeur à l'autre mais ne font aucune utilisation spécifique des possibilités des processeurs (pour conserver la compatibilité), et n'assurent pas la portabibilité complète (résultats identiques d'une machine à l'autre). Bien que très complèxes, elles ne peuvent utiliser les processeurs de la façon la plus efficace (par exemple le "branch prediction", le "data prefetch", la gestion des caches de données, ceci pour augmenter au maximum le parallélisme possible par les pipelines multiniveaux des processeurs actuels).
Malheureusement, les très bonnes librairies mathématiques portées sur les processeurs actuels sont souvent très chères : regardez le coût des licences des excellentes librairies mathémétiques d'Intel et d'AMD, qui ont pourtant le défaut de ne pas être compatibles entre elles: cela oblige à lier au moins les deux librairies, en plus d'une implémentation générique pour les processeurs d'autres fabriquants non supportés!
La parade: utiliser des librairies de calcul pour Fortran (qui, elles, sont totalement portables et très bien optimisées), mais sont assez compliquées (pas impossible) à utiliser depuis le langage C ou C++, et respectent les normes IEEE à la lettre (d'où un gain évident en portabilité, ce qui ne nécessite pas à l'installation d'un logiciel de forunir plein de versions différentes, et simplifie grandement le déploiement des applications).
Si vous n'êtes pas encore convaincus de l'ampleur de la tâche, regardez les sources de la librairie mathématique de GNU CC et comment le support de différents processeurs a été patiemment inclus: cela a pris des dizaines années, et aucun programmeur ne pourrait refaire tout seul un tel investissement (qui comprend aussi la détection et le contournement de bogues connus de certains modèles de processeurs, bogues et limitations beaucoup plus fréquentes que vous pensez car il est devenu presque impossible aujourd'hui de fabriquer un processeur totalement parfait dont aucune fonction n'a été désactivée APRES fabrication et tests, ou dont certaines fonctions se désactivent automatiquement avec le temps par un autotest au démarrage: méfiance avec vos overclockings de processeur: vous risquez bien d'obtenir à la fin un processseur moins performant qu'à son achat mais qui continue à fonctionner quand même!).
21 janv. 2007 à 10:19
Par contre, le SSE est disponible a partir du Celeron (Pentium 3) 533A donc la majeur partie des P3 l'ont ^^ (chez AMD c'est sur les Athlon XP minimum, je sais pas par contre pour les Durons...)
20 janv. 2007 à 19:05
Pourquoi je le mets ici en asm:
à simple but didactique comme d'hab, les sources sur CS sont là pour ça. Comme actuellement j'ai un contrat pour coder en SSE un moteur de statistiques, je me suis dis qu'il pouvait être intéressant de présenter ce type de codage dans un module C sur cppfrance.
20 janv. 2007 à 18:37
Suis-je le seul à avoir remarqué des différences de conversion entre le C et l'asm ?
Quel intérêt as-tu vu à l'écrire en asm (mis à part le plaisir de le faire) ?
20 janv. 2007 à 01:28
DWORD *p;
char buf[28]; // A REMPLIR PAR USER
double d;
d = atof(buf);
p = (DWORD*) &d;
ultoa(*(p+1), buf, 16); // PARTIE HAUTE DU FLOAT64
ultoa(*p, buf, 16); // PARTIE BASSE DU FLOAT64
19 janv. 2007 à 20:15
Merci pour ce code :) C'est toujours sympa de voir un peu de bas niveau (et j'avoue que je ne me promène pas sur asmfr souvent).
J'ai une question : j'ai l'impression qu'on peut obtenir les mêmes résultats en C pur, avec le code que je place ci-dessous, mais autant pour des valeurs comme 13.4 j'obtiens la même chose, autant pour 13.12897 ou encore 13.999999999 j'ai une différence sur le LSB. Quelqu'un a une explication ?
Code à ajouter au projet :
void test(void)
{
char buffer[256];
char petit_buffer[16];
unsigned char temp_8octets[8];
double temp_db = 0;
GetWindowText(htxt, buffer, 256);
sscanf(buffer, "%lf", &temp_db);
buffer[0] = 0;
float temp_fl = temp_db;
CopyMemory(temp_8octets, &temp_db, 8);
for (int i = 7; i >= 0; i--)
{
if ( sprintf(petit_buffer, "%X", (unsigned int)(temp_8octets[i])) == 1 )
strcat(buffer, "0");
strcat(buffer, petit_buffer);
}
strcat(buffer, "\n");
CopyMemory(temp_8octets, &temp_fl, 4);
for (int i = 3; i >= 0; i--)
{
if ( sprintf(petit_buffer, "%X", (unsigned int)(temp_8octets[i])) == 1 )
strcat(buffer, "0");
strcat(buffer, petit_buffer);
}
MessageBox(0, buffer, 0, 0);
return;
}
19 janv. 2007 à 17:55
19 janv. 2007 à 17:36
19 janv. 2007 à 16:20
avec toutes les connaissances qu'il a il aurait pu tout faire en asm facilement
je n'ai rien contre l'asm en C/C++ mais quand le ratio d'asm est plus élevé que celui du C autant y aller tout en asm ou bien poster sur asmfr.com
c'est mon avis
19 janv. 2007 à 06:35
on ne va pas aller chercher un morceau de la source sur chaque site CS ^^
19 janv. 2007 à 05:07