FONCTIONS DE TRAITEMENT RAPIDE DE CHAINES ET FICHIER
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
1 avril 2004 à 11:36
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 10 avril 2004 à 16:43
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 10 avril 2004 à 16:43
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/21614-fonctions-de-traitement-rapide-de-chaines-et-fichier
https://codes-sources.commentcamarche.net/source/21614-fonctions-de-traitement-rapide-de-chaines-et-fichier
10 avril 2004 à 16:43
Voila exemple complet dans un prog win32.
Par principe si tu ecris une func en asm, faut la 'depouiller' afin de la controler completement, donc pas de declaration de variable ni 'return' ni rien d'autre. Si on mixe code C et ASM on gene l'optimisation du compilo, alors full asm ou rien.
Regarde strBinToInt(), j'ai mis en fastcall pour eviter empilage de param, on passe dans registre (ECX), ne pas oublier le ret final, ici avec 0 cause que rien de mis sur la pile.
#include <windows.h>
char szbuff[60];
char szappname[] = "Sample ASM inline";
__declspec(naked) int __fastcall strBinToInt(char *psz)
{ // ECX = psz, EDX autre param mais niet ici
__asm {
xor eax, eax
next:
mov dl, byte ptr[ecx]
sub dl, 48
jc short tointExit
cmp dl, 1
ja short tointExit
shl eax, 1
inc ecx
or al, dl
jmp short next
tointExit:
ret 0
}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, PSTR szcmdline, int)
{
int r;
r = strBinToInt("001101101");
itoa(r, szbuff, 10);
MessageBox(0, szbuff, szappname, 0);
return 0;
}
8 avril 2004 à 20:51
a+
1 avril 2004 à 14:53
"Mieux vaut un C optimisé qu'un médiocre ASM".
Les compilateurs modernes intègrent une série de règles d'optimisation de code performantes et à ce jour seul un bon programmeur ASM sera à même d'améliorer le code généré par le compilateur C.
De ce fait, n'ajouter que du (bon) code ASM que si la section est critique et requiert un contrôle total me semble fondamental.
Je serai bien curieux de voir le rapport de performances entre le code "classique" de string.h compilé en Release de VC++ et ton code ASM non retouché
L'effort est louable mais ne perds pas de vue le rapport efficacité réelle/travail founi
1 avril 2004 à 11:36
copyfile() procede octet par octet si j'ai bien compris, auquel cas faudra pas etre presse.
ASM: le tout n'est pas d'empiler des instructions pour faire joli, faut viser la performance. C'est loin d'etre le cas ici:
- instructions longues: mov eax, 0 au lieu de xor eax, eax
- emploi de ebx a sauvegarder quand les generaux suffisent.
- Les boucles ne sont pas deroulees.
etc ....
Mieux vaut un C optimise que du mauvais asm, un compilo moderne aura vite fait mieux.
Le prends pas mal mais revois ta copie.
BruNews, Admin CS, MVP Visual C++