FONCTIONS DE TRAITEMENT RAPIDE DE CHAINES ET FICHIER

Signaler
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
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

Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21
Retour de Seattle, j'ai un peu plus de temps.
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;
}
Messages postés
16
Date d'inscription
dimanche 2 février 2003
Statut
Membre
Dernière intervention
3 juin 2008

Merci pour votre aide à tous. Voilà une nouvelle version, même si y a encore du boulot. Y'a plus qu'à dégrossir ? j'y retourne.
a+
Messages postés
527
Date d'inscription
vendredi 14 septembre 2001
Statut
Membre
Dernière intervention
6 octobre 2008
3
Cette source est extrêmement intéréssante pour illustrer les propos de BruNews. Le paradigme de base est bien celui de ce dernier
"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
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21
Un fichier peut exister meme si on ne peut pas l'ouvrir, suffit qu'il ait ete ouvert en exclusif avant, donc file_exist a refaire.
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++