Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1004 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2  3
Page Suivante
Auteur Sujet :

[memcpy] L'importance de l'optimisation dans la copie des données

n°798521
Taz
bisounours-codeur
Posté le 17-07-2004 à 15:06:36  profilanswer
 

Reprise du message précédent :
en tout cas, je pense pas que memcpy soit le point chaud d'une appli pédagogique.

mood
Publicité
Posté le 17-07-2004 à 15:06:36  profilanswer
 

n°798538
christophe​_d13
L'efficacité à tout prix.
Posté le 17-07-2004 à 15:33:49  profilanswer
 

yawen> Je ne traîte personne de "con". Ce que je déplore : La fausse "connaissance" - Ou croire que l'on sait. Alors qu'en fait, on ne sait jamais. J'ai aussi appris sur le tas, mais je me suis documenté, j'ai beaucoup lu et analysé pour comprendre et pas simplement recopier des programmes. On peut toujours apprendre par soi-même, mais cela demande de la rigueur. Mais même en cours, les élèves (souvent) considèrent les cours de prog comme du français, des maths, histoire... C'est là qu'est le problème.
Pour tes problèmes, il t'est toujours possible de te documenté pour savoir si ce que tu fait est cohérent. Ce n'est pas parce qu'un prog fonctionne qu'il n'est pas exempt de bug ou d'erreur de programmation. Je découvre parfois des erreurs dans les applis que l'on vend...
 
Taz> Tu vas comprendre avec un petit exemple :
- Faire un logiciel pédagogique performant, élégant (beau  design), fonctionnel, ergonomique, avec des animations, des effets... Le tout sous Windows et sur des bécanes anciennes.
Le plus gros problème n'est pas la pédagogie, même si cela représente souvent 50% du temps de dvlp, mais la manipulation graphique pose de gros soucis de vitesse. D'où l'intérêt d'un memcpy performant.
On ne peut pas demander à une école de changer son parc informatique sous prétexte que les logiciels nécessitent des machines gourmandes (comme c'est le cas pour Director et Flash).
 
Up> Il y a encore trois ans, je bossais avec Visual C 1.51 pour faire les applis sous Windows 3.11. On en vend toujours !


Message édité par christophe_d13 le 17-07-2004 à 15:36:30
n°798544
christophe​_d13
L'efficacité à tout prix.
Posté le 17-07-2004 à 16:00:44  profilanswer
 

La suite...
 
Je vous livre une "grosse" astuce pour copier des éléments plus rapidement se trouvant en RAM, c'est le bloc prefetching.
 
En fait, cela consiste à faire des transfert par bloc, il sont temporairement stocké dans le cache L1 (merci la polution).
On va prendre un exemple concret :
 
-> On dispose d'un processeur ayant un cache L1 de 16Ko (on va le poluer entièrement). Les pentium std dispose de 8Ko.
-> Le processeur dispose de lignes de cache de 64 octets (32 octets sur pentium std).
-> On doit copier un bloc de 2Mo d'une zone vers une autre.
 
1. On découpe le bloc de 2Mo en 128 blocs de 16Ko.
 
2. On charge dans le cache 16Ko de données :

2a. Lecture de 4 octets (en réalité, cela provoquera un chargement de la ligne de cache entière soit 64 octets) dans un registre de la source dans un registre (mov eax, [esi])
2b. On se déplace au 64 octets suivant (add esi, 64)
2c. On boucle au total 256 fois.


On peut faire un léger unrool de cette boucle pour améliorer la vitesse.
Maintenant que les 16Ko sont dans le cache, la lecture va être ultra-rapide !
 
3. On copie les données en lisant avec movq (MMX) et en écrivant avec movntq (SSE) - Il est possible d'utiliser movaps(SSE) et movntps(SSE). On peut utiliser également les fonctions FPU (fld/fstp) ou CPU, mais on va poluer le cache. Cela dit dans un processeur sans SIMD, on a pas le choix.
 
4. Il ne reste qu'à reboucler sur 2/3 pour copier les 2Mo.
 
 
 
Cette technique permet d'augmenter le débit de +50% à +100% suivant les machines. L'augmentation est souvent très importantes car les processeurs disposent souvent d'une ligne d'écriture de 16 ou 32 octets.
 
On est pas obliger d'utiliser une taille de 16Ko. Mais même si on utilise une taille de 8Ko ou 4Ko, le L1 sera complètement pollué si la taille totale dépasse sa propre taille (SizeCopy>SizeL1).
Le cache L2 est également souvent pollué puisque les données sortantes du L1 vont se retouver dans le L2.
 
Il existe également un variante (que j'ai mise au point), c'est le Half-BlocPrefetching ou Middle-BlocPrefetching. Cela consiste à organiser le code pour d'abord remplir la ligne cache puis finir la copie :
 

           mov     ecx, lSize
            mov     edx, 64
 
            mov     esi, pSource
            xor     eax, eax
 
            mov     edi, pTarget          
            and     ecx, 0xFFFFFFC0
 
        _$memcpyloop:
            fld     qword ptr [esi+eax]      
            fld     qword ptr [esi+32]      
            fxch    st(1)                    
            fstp    qword ptr [edi+eax]
            fstp    qword ptr [edi+32]
             
            fld     qword ptr [esi+56]
            fld     qword ptr [esi+48]
            fld     qword ptr [esi+40]
            fld     qword ptr [esi+24]
            fld     qword ptr [esi+16]
            fld     qword ptr [esi+ 8]
 
            lea     esi, [esi+edx]
            sub     ecx, edx
 
            fstp    qword ptr [edi+ 8]
            fstp    qword ptr [edi+16]
            fstp    qword ptr [edi+24]
            fstp    qword ptr [edi+40]
            fstp    qword ptr [edi+48]
            fstp    qword ptr [edi+56]
             
            lea     edi, [edi+edx]            
            jnz     _$memcpyloop


Dans l'exemple, on utlise également les propriétés du WriteBack. L'écriture juste après la lecture (5 premières lignes de la boucle) est partiellement masqué car il faut un grand nombre de cycles pour charger la données se trouvant en RAM (ou dans le cache L2 ?).
 
N'oublions pas que memcpy standard bousille complètement le cache L1/L2


Message édité par christophe_d13 le 17-07-2004 à 19:40:39
n°799350
yawen
Posté le 19-07-2004 à 10:52:14  profilanswer
 

christophe_d13>

Citation :

On peut toujours apprendre par soi-même, mais cela demande de la rigueur.


qu'est ce que tu entends par rigueur ?
 

Citation :

il t'est toujours possible de te documenté pour savoir si ce que tu fait est cohérent.


Me documenter où ? parce que si par exemple je veux savoir si la structure globale d'un de mes programmes est correcte (i.e. organisation des classes, héritages, constructeurs/destructeurs, etc...), le seul moyen de faire que je vois est de regarder comment font les autres et de comparer... ou alors de récupérer des cours de programmation et de les lire, si c'était ça que tu voulais dire...
 
désolé de sortir du sujet, au fait...
 
Taz>

Citation :

en tout cas, je pense pas que memcpy soit le point chaud d'une appli pédagogique.


tout dépend du niveau de l'application, qu'elle soit pédagogique ou pas... dans tous les cas, comprendre comment fonctionne le pc aux plus bas niveaux (i.e. assembleur, gestion de la mémoire, etc) ne peut-être que très enrichissant. Tu serais le premier à gueuler sur ceux qui font des conneries en programmation parce qu'ils ne comprennent pas ce qu'il y a derrière leur langage

n°799587
Joel F
Real men use unique_ptr
Posté le 19-07-2004 à 14:12:28  profilanswer
 

n'empeche que ca reste de la sodomie de drosophile :|

n°799936
christophe​_d13
L'efficacité à tout prix.
Posté le 19-07-2004 à 20:38:19  profilanswer
 

Et l'altivec, c'est quoi ?
C'est comprendre mieux le matériel non ?
 
Aujourd'hui on est plus à faire des progs en ModeX ou tenter de faire des scrolls rapides et fluides. Mais juste gagner le plus de temps pour faire autre chose et décharger le CPU pour avoir de la marge et en rajouter.
Je précise que je suis programmeur système à la base (et optimiseur). Donc j'ai toujours développé en travaillant d'abord sur le matériel pour tenter de trouver un max de subtilités ou d'astuces.
 
Dans une appli que je développe en parallèle, je dois charger une cinquantaine d'images, les redimensionnés, les déplacer...  Tout cela prend du temps, et je ne peux savoir à l'avance quoi faire puisque tout dépend de l'utilisateur.
Après avoir fortement améliorer mes routines de chargement et de rotation, il ne me reste que mes bitblt et les bitblt (quand la transparence n'est pas géré), c'est du memcpy amélioré.
J'ai fait un test avec le bitblt de DirectDraw, celui de la GDI et le miens. Les BitBlt de DirectDraw est 16% plus rapide que celui de la GDI, et le miens est environ 60% plus rapide que celui de DirectDraw. Tout ça simplement car je sais à l'avance où se trouve l'image source et que le code est choisi pour être le plus rapide suivant l'emplacement.


Message édité par christophe_d13 le 19-07-2004 à 20:40:07
n°801364
Joel F
Real men use unique_ptr
Posté le 20-07-2004 à 23:35:39  profilanswer
 

christophe_d13 a écrit :


Et l'altivec, c'est quoi ?


Une vrai extension SIMD [:dawa]
 

christophe_d13 a écrit :


C'est comprendre mieux le matériel non ?


Non.
 

christophe_d13 a écrit :


Aujourd'hui on est plus à faire des progs en ModeX ou tenter de faire des scrolls rapides et fluides. Mais juste gagner le plus de temps pour faire autre chose et décharger le CPU pour avoir de la marge et en rajouter.


Ben c'est pas l'impression que tu donnes
 

christophe_d13 a écrit :


Je précise que je suis programmeur système à la base (et optimiseur).  


Aucun rapport.
 

christophe_d13 a écrit :


Donc j'ai toujours développé en travaillant d'abord sur le matériel pour tenter de trouver un max de subtilités ou d'astuces.


Ben c'est mal .... désolé.  

n°805170
christophe​_d13
L'efficacité à tout prix.
Posté le 24-07-2004 à 09:38:16  profilanswer
 

Joel> Sur PC, t'as pas beaucoup de choix. Il en va de même sur les Atari ST et Amiga. On programmait plus avec de l'astuce qu'autre chose.
Sur toutes les machines, il y a des choses (matérielles) à connaitre : les latences cache et mémoire, les prédictions de saut du CPU...
Les seuls processeurs où il n'y pas besoin de connaître tout cela, ce sont les DSP (genre le DSP16). Toutes les instructions tournent en 1 ou 2 cycles et rien ne peut modifier la rêgle.
Alors s'il faut ruser pour gagner 1, 2 ou 10% de perfs en plus (ou plus encore), et bien si le temps le permet, il faut le faire.
 
J'oubliais, seul le résultat compte dans l'optimisation (cf concours No 4 dans la partie ASM), peu importe la méthode du moment que le logiciel est plus performant.

n°805179
maze123coo​l
Posté le 24-07-2004 à 10:18:51  profilanswer
 

christophe_d13 a écrit :

Alors s'il faut ruser pour gagner 1, 2 ou 10% de perfs en plus (ou plus encore), et bien si le temps le permet, il faut le faire.


 
Ca fait plaisir de lire cela, je suis entièrement d’accord avec toi. :sol:  
 

n°805578
chrisbk
-
Posté le 25-07-2004 à 01:55:05  profilanswer
 

christophe_d13 a écrit :


N'oublions pas que memcpy standard bousille complètement le cache L1/L2


 
si t'en est tellement a vouloir preserver ton cache, pkoi t'utilises pas movntq ?
 

Citation :


void _MemoryCopy_MMX_SSE_hpf_fcache_o08_br01bw01_s0064 ( void * pTarget, void * pSource, long lSize )
      {
            __asm {
                  push        ebx


 
y sert a rien ton push ebx :o (vs te le protege)
si tu veux gagner deux cycles sur ta routine, tu vire ton mov edx,64 et tu remplaces tes add machin, edx par des add machin,64, idem avec EAX (pkoi diable se priver d'un registre pour juste y foutre une constante ?), et tu remplace l'utilisation de ESI par EDX et EDI par eax, ca t'alege tes prolog / epilogue de fonction :o
 
 
(pis tiens, fous ta fonction en __declspec(naked) et hop, a la dure)


Message édité par chrisbk le 25-07-2004 à 02:00:16
mood
Publicité
Posté le 25-07-2004 à 01:55:05  profilanswer
 

n°805594
christophe​_d13
L'efficacité à tout prix.
Posté le 25-07-2004 à 02:54:37  profilanswer
 

Citation :

si t'en est tellement a vouloir preserver ton cache, pkoi t'utilises pas movntq ?


Comme je l'ai déjà écrit, j'ai globalement 4 routines de copie : Pour maximiser le cache L1, le L2, la RAM et un compromis global.
Au total, j'ai réduit mes routines au nombre de 14. Certaines utilisent exclusivement le CPU, d'autres la FPU, ou le MMX, MMX+SSE/3DNow!, SSE...
Ensuite, movntq c'est une routine SSE non compatible MMX. Donc très bien pour préserver le cache mais sur une Pentium II ou Pentium MMX, c'est nada.
 

Citation :

y sert a rien ton push ebx :o (vs te le protege)


C'est également ce que je croyais (c'est écrit dans la MSDN) mais je me suis rendu compte que les optimisations (-O2) de VC avaient des comportement bizarres avec les registres. Après plusieurs investigations, j'ai pris l'habitude de sauver EBX et parfois même EFLAGS (d'ailleurs, je pourrais mettre EBX dans une variable plutôt que via SS:ESP, mais cela limite la portabilité de certaines routines, et surtout, je peux rechercher plus facilement mes "push/pop ebx" pour les enlever, même si maintenant j'utilise une macro selon le compilo).
 

Citation :

si tu veux gagner deux cycles sur ta routine, tu vire ton mov edx,64 et tu remplaces tes add machin, edx par des add machin,64, idem avec EAX (pkoi diable se priver d'un registre pour juste y foutre une constante ?)


Car une constante "immédiat" alourdi la taille du code et surtout, on perd l'alignement par 2 ou 4 des instructions :
mov eax, ebx = 2 octets
mov eax, 8 = 3 octets
Grâce à cela, on gagne un poil de vitesse (en fait on évite de ralentir le chargement).
Update> C'est pourtant ce que je faisais pour mes routines de texturages puisque j'utilisais du code-morphing souvent avec les immédiat pour avoir des variables locales en Read-Only. Mais difficile à faire sous Windows. D'ailleurs si quelqu'un à trouver une astuce (pour modifier le code qui s'éxécutera 10 lignes plus bas après un JMP), je suis preneur.
 
 

Citation :

...et tu remplace l'utilisation de ESI par EDX et EDI par eax, ca t'alege tes prolog / epilogue de fonction :o


En fait, dans les docs Intel, AMD et Cyrix, il n'y pas de différence dans l'utilisation des registres globaux, sauf pour ESP. Aucun de ces derniers n'ajoute de préfixe. En fait c'est le compilateur qui fait ce choix, dans TASM, il y avait, si mes souvenirs sont bons une option pour ajouter automatiquement les bons préfixes suivant les registres (ES pour DI).
Je rappelle par défaut (en adressage 32 bits) que tous les registres travaillent sur DS sauf EBP et ESP qui travaillent du SS. De toute façon, dans la majorité des programmes, DS et SS ont la même valeur, c'est le même sélecteur.
 
 
J'espère avoir été suffisament clair sur les choix que j'ai fait.


Message édité par christophe_d13 le 25-07-2004 à 03:00:24
n°805595
chrisbk
-
Posté le 25-07-2004 à 03:02:06  profilanswer
 

christophe_d13 a écrit :


Car une constante "immédiat" alourdi la taille du code et surtout, on perd l'alignement par 2 ou 4 des instructions :
mov eax, ebx = 2 octets
mov eax, 8 = 3 octets
Grâce à cela, on gagne un poil de vitesse (en fait on évite de ralentir le chargement).


 
un poil faux, une constante immediate doit avoir la meme taille que l'operande de destination
donc mov eax,8 => 6 octets (ou 5, on peut coder mov eax, en un seul octet)
(c'est dans l'adressage, genre [eax + 2] que l'on peut faire varier la taille de l'operande (via les tres sexy mod bits))
(ca aide pas trop ton alignement sur 4, mais bon, aligner les instructions, bonjour)
 

Citation :


En fait, dans les docs Intel, AMD et Cyrix, il n'y pas de différence dans l'utilisation des registres globaux, sauf pour ESP. Aucun de ces derniers n'ajoute de préfixe. En fait c'est le compilateur qui fait ce choix, dans TASM, il y avait, si mes souvenirs sont bons une option pour ajouter automatiquement les bons préfixes suivant les registres (ES pour DI).


 
oué, mais moi je te parle des conventions d'appels de fonction, une fonction est tenue de rendre EDI / ESI / EBP / ESP et EBX dans l'etat ou elle les a trouvé, le reste elle fait ce qu'elle veut avec. (sinon ca devient l'anarchie). Donc quand tu tapes dans edi (par ex), le compilo va te rajouter un push/pop dans les epilogues / prologue


Message édité par chrisbk le 25-07-2004 à 03:06:10
n°805596
christophe​_d13
L'efficacité à tout prix.
Posté le 25-07-2004 à 03:29:18  profilanswer
 

Citation :

un poil faux, une constante immediate doit avoir la meme taille que l'operande de destination  
donc mov eax,8 => 6 octets (ou 5, on peut coder mov eax, en un seul octet)  
(c'est dans l'adressage, genre [eax + 2] que l'on peut faire varier la taille de l'operande (via les tres sexy mod bits))  
(ca aide pas trop ton alignement sur 4, mais bon, aligner les instructions, bonjour)


Reli bien tes docs. Un immédiat peut être codé sur 8 ou 32 bits même si le registre est sur 32 bits.
 
Lis bien cela :
add esi, 64
est codé : 83 c6 40
 
à l'inverse :
add esi, 128  
est codé : 81 c6 80 00 00 00
 
enfin :
add esi, ecx
est codé : 03 f1
 
Elle est pas belle la vie ?
 
 

Citation :

oué, mais moi je te parle des conventions d'appels de fonction, une fonction est tenue de rendre EDI / ESI / EBP / ESP et EBX dans l'etat ou elle les a trouvé, le reste elle fait ce qu'elle veut avec. (sinon ca devient l'anarchie). Donc quand tu tapes dans edi (par ex), le compilo va te rajouter un push/pop dans les epilogues / prologue


Tu as raison, je ne l'avais pas compris comme cela. Mais les comportement bizarres de VC avec EBX me font douter de l'éfficacité du compilateur. Mais tu as bien raison, il faut rendre tous les registres tels-quels (sauf bien sûr pour edx:eax).


Message édité par christophe_d13 le 25-07-2004 à 03:41:07
n°812198
maze123coo​l
Posté le 01-08-2004 à 09:49:25  profilanswer
 

@christophe_d13:
 
Et globalement obtiens-tu qqchose de plus rapide que le memcpy_amd ?
 
 

n°838716
Elpopo
Posté le 01-09-2004 à 13:39:35  profilanswer
 

Je suis débutant en assembleur, et je n'arrive pas à passer le memcpy_amd en fichier asm. En effet j'essaye de porter un programme de traitement d'images sous le compilateur AMD64 de VS Whidbey, et ce dernier ne prend pas en compte les directives __asm. Si quelqu'un pouvais m'aider. D'avance merci.

n°843732
jesus_chri​st
votre nouveau dieu
Posté le 06-09-2004 à 21:57:48  profilanswer
 

Elpopo a écrit :

Je suis débutant en assembleur, et je n'arrive pas à passer le memcpy_amd en fichier asm. En effet j'essaye de porter un programme de traitement d'images sous le compilateur AMD64 de VS Whidbey, et ce dernier ne prend pas en compte les directives __asm. Si quelqu'un pouvais m'aider. D'avance merci.

l'assembleur inline __asm {...} n'est plus et ne sera plus supporté par visual. Et c'est bien dommage. Tu peux te reporter vers MASM64 (ml64.exe) qui compile du vrai code assembleur. Si t'arrives à t'en servir c'est que t'es très fort car il n'y a pas de documentation et appeler ml64 /? affiche l'aide de MASM 6.

n°843884
christophe​_d13
L'efficacité à tout prix.
Posté le 07-09-2004 à 08:51:24  profilanswer
 

maze123cool> J'ai des gains de temps importants puisque j'ai un programme qui manipule une grosse quantité de données (images).
Sur une machine récente, le gain n'est pas vraiment perceptible car c'est assez fluide, mais sur des P3-600, la fluidité devient vraiment très bonne !
A l'inverse, pour vous donner une idée :
Une fonction de copie (bitblt) à un gain de vitesse de x2 à x5 suivant le contexte et le processeur.
Mes fonctions de stretching sont passées de 28cps à 132cps.
Les fonctions memcpy n'ont que peu d'interêt puisque dans ce programme elles ne manipulent que de très petites quantités de données (moins de 1 à 256 octets).
Par contre ma gestion de cache mémoire y gagne énormément puisque je travaille sur des blocs (1 à 4 Ko). Le gain est variable, l'amélioration est perceptible, mais je ne l'ai pas mesuré.
 
Up> Dans tous la plupart des cas, c'est la technique du block prefetching qui apporte un gain de vitesse ainsi qu'une copie 64 bits (FPU ou MMX). Le hardware prefetching apporte rarement des gains importants.
Dans les routines de copie où la taille est définie lors de la compilation, il y a là un travail interressant à faire...
 

Citation :

l'assembleur inline __asm {...} n'est plus et ne sera plus supporté par visual. Et c'est bien dommage.


J'attend de voir ça... D'autant qu'avec gcc le support sera toujours présent.


Message édité par christophe_d13 le 07-09-2004 à 08:55:34
n°843969
jesus_chri​st
votre nouveau dieu
Posté le 07-09-2004 à 10:24:14  profilanswer
 

christophe_d13 a écrit :


J'attend de voir ça... D'autant qu'avec gcc le support sera toujours présent.


Ouais enfin l'asm inline de gcc c'est une horreur : du AT&T dans des strings...
Je préfère passer par MASM.

n°844016
christophe​_d13
L'efficacité à tout prix.
Posté le 07-09-2004 à 11:35:28  profilanswer
 

Juste pour illustrer l'asm de at&t... Voici une petite routine au qui affiche un point en PAL8...

Code :
  1. asm ("
  2. __mem_setpixel8:
  3. pushl     %ebp
  4. movl      %esp,%ebp
  5. pushw     %es
  6. movl      8(%ebp),%esi ;//Charge l'adresse du hGDC dans esi
  7. movl      12(%ebp),%edi ;//Charge x dans edi
  8. movl      16(%ebp),%ebx ;//Charge y dans ebx
  9. movl      0x18(%esi),%eax     ;//Charge mul and adress
  10. movl      0x10(%esi),%edx     ;//charge segment selector
  11. movl      20(%ebp),%ecx       ;//charge la couleur          : %ecx
  12. addl      (%eax,%ebx,4),%edi
  13. movw      %dx,%es
  14. movb      %cl, %es:(%edi)
  15. popw      %es
  16. popl      %ebp
  17. ret
  18. " );


Message édité par christophe_d13 le 07-09-2004 à 11:36:20
n°844300
Elpopo
Posté le 07-09-2004 à 16:09:46  profilanswer
 

jesus_christ a écrit :

l'assembleur inline __asm {...} n'est plus et ne sera plus supporté par visual. Et c'est bien dommage. Tu peux te reporter vers MASM64 (ml64.exe) qui compile du vrai code assembleur. Si t'arrives à t'en servir c'est que t'es très fort car il n'y a pas de documentation et appeler ml64 /? affiche l'aide de MASM 6.


 
 
je suis presque arrivé à passer le fichier memcpy_amd.cpp vers un code MASM mais je ne vois pas pourquoi il me remplace la ligne suivante :
     mov [CPU_Type], eax
par celle-ci (en code machine) :
     mov dword ptr cs:[_CPU_Type (42D91Ch)],eax  
Et grace à ce remplacement j'ai une magnifique exception !
 
Le MASM est en plus super documenté j'adore !  :cry:  
 
note : CPU_Type est un unsigned long.

n°844469
jesus_chri​st
votre nouveau dieu
Posté le 07-09-2004 à 19:38:23  profilanswer
 

Avec MASM quand tu as une variable* il ne vaut mieux pas mettre de crochets autour sauf pour lea.
 
exemple :
 

.data
variable DWORD ?
 
.code
 
mov eax, variable
not eax
mov variable, eax


 
*En assembleur la notion de variable, de pointeur et de référence est confondu.

n°844505
nithril
Posté le 07-09-2004 à 21:32:23  profilanswer
 

A noter qu'il existe aussi NASM pour linux, donc l'asm at&t n'est pas une fatalité :)

n°844518
jesus_chri​st
votre nouveau dieu
Posté le 07-09-2004 à 21:51:51  profilanswer
 

Nithril a écrit :

A noter qu'il existe aussi NASM pour linux, donc l'asm at&t n'est pas une fatalité :)

ouais des trucs portables il y en a, je pense simplement que :
 
- l'assembleur est assez répulsif comme ça pour en + se tapper une syntaxe dégueue.
- MASM devrait devenir une référence car c'est le meilleur assembleur actuel, il est toujours mis à jour, gratuit et utilisable sous Unix au prix d'une petite bidouille (il faut lui faire faire un OMF qui est ensuite converti en ELF avec objcopy).

n°844546
nithril
Posté le 07-09-2004 à 22:48:25  profilanswer
 

euh, NASM c'est quand meme une reference

n°844907
christophe​_d13
L'efficacité à tout prix.
Posté le 08-09-2004 à 11:47:32  profilanswer
 

Une fois l'habitude de coder en at&t, je le trouve plus evident.

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[ASM] Optimisation MMX/SSE d'une boucle[Java RSA] cryptage de données avec une clé publique
VBA SQL recuperer données d'un SELECTinterface et traitement données fichier
[VBA Exc] Récup de données dans un classeur fermé! (cf 2ème post)pile memoire - modification donnees
Comment transferer des donnees d'une base a l'autre ? ( access )Insertion de données excel dans un tableaux phpmyadmin
Problème avec la copie de variables[PHP/HTML] Recupéré des données vers le HTML
Plus de sujets relatifs à : [memcpy] L'importance de l'optimisation dans la copie des données


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR