J'ai regardé ta fonction bnzeromemAL de pret la, c'est du bon, par contre quand tu dit "Utiliser les 'AL' quand tu es certain de l'alignement sur 4 de destination" tu veux dire aligner sur 4 octets ? parce que la ça serais plutot 8 puisque tu efface 8 par passe :
*((DWORD*) p) = 0;
*((DWORD*) (p + 4)) = 0;
Cool merci BruNews ! j'ai plus le vilain message CRT :-)
J'avais un autre message quand j'avais mis "Ignore All Default Libraries" à yes :
error LNK2001: unresolved external symbol __chkstk
Pour ceux qui l'ont eu c'est à cause d'un buffer trop gros, j'en avait un a 768 WCHAR je l'ai descendu a 256 et plus de message même avec cette option activée.
trop lent par octet.
Versions pour buffers alignés ou non. Utiliser les 'AL' quand tu es certain de l'alignement sur 4 de destination (souvent le cas dans code propre).
Est ce que par hasard vous auriez un set de fonction que le compilo ne detecte pas comme étant similaire a celle de la CRT ?
Tu disais BruNews que tes fonction asm n'était pas détectée ? pourrais tu publier tes fonctions ? j'ai juste besoin de ces 3 la , memcpy, memset et memcmp.
J'ai trouvé un autre moyen de régler ces problèmes de memset: carrément redéfinir memset
Au début le compilo ne veut pas (il dit fonction intrinsèque, non définissable)
J'ai trouvé qu'il faut juste mettre un pragma avant:
#pragma function(memset)
void* memset(void* buffer, int c, unsigned int num)
{
// notre fonction memset
}
Ca nous permet de pouvoir écrire des {0} ou ZeroMemory par exemple et de ne pas changer nos habitudes
Mais cette solution a un gros onconvénient: elle est incompatible avec l'option /GL de compilo (optimisation globale du programme). On est alors obligé de la désactiver, et du coup /LTCG aussi
Finalement cette solution ne vaut pas le coup, mais je voulais juste vous signaler l'existence de ce pragma
switch (longueur-(taille32*2)) // astuce: le bloc du switch n'accepte que les valeurs 3, 2 et 1. si taille32=1 (quand longueur=4) le resultat sera 3, ce qui faussera tout. On multiplie taille32 par 2 pour éviter ce cas.
Voici la fonction que j'utilise:
void FillMem(void *destination, DWORD longueur,BYTE octet)
{
// Obtenir un pointeur sur DWORD:
DWORD* destination32=(DWORD*)destination;
// Calculer la taille en DWORDs:
DWORD taille32=longueur/4;
// Former un DWORD dont chaque octet contient la valeur de notre octet:
DWORD groupe=(octet*0x1000000 | octet*0x10000 | octet*0x100 | octet);
// Si la longueur est inférieure à 4 on met juste les octets qu'il faut:
switch (longueur-(taille32*2)) // astuce:
{
case 3: ((BYTE*)destination)[longueur-3] = octet;
case 2: ((BYTE*)destination)[longueur-2] = octet;
case 1: ((BYTE*)destination)[longueur-1] = octet;
}
// Remplir par notre DWORD tant que la taille est supérieure à 0:
while( taille32-- > 0 ) *(destination32++) = groupe;
}
Elle ne doit pas être aussi rapide que celle de Brunews, mais elle fonctionne très bien. Je la soumets à vos remarques.
Salut,
Moi aussi j'ai remarqué ce petit problème. Le pire c'est que, dans le même code, certains appels à ma fonction se font normalement alors que d'autres sont remplacés par _memeset. J'ai résolu le problème en ajoutant /Ob1 aux options du compilateur. Je comprends pas trop mais ça marche.
he he, tu as sentis venir ??? je démarrais justement une lib perso pour memset et memcpy, n'y aura plus qu'à mettre la lib dans dossier du proj et inclure son h.
Je vais faire 2 versions de chaque (enfin j'y réfléchis), aligné et non aligné.
Il fait tellement plus fort, on ne va plus s'étonner de si peu.
Essaie la compil "profil guided optimization" et vérifie le listing asm à chaque étape, il déplace des bouts de code et réécrit si besoin pour gagner qlqs cycles, un truc de fou.
Me semble que G. Vollant a mis des trucs là dessus sur son site.
ça je l'ai déjà eu, si la signature complète de la fonction ressemble à une intégrée de la CRT, il met la sienne.
J'avais résolu en mettant du code asm en remplacement.
Nouvel épidose: j'utilise le code de racpp pour voir quelles sont les dépendances éventuelles.
J'ai cette fonction, pour remplacer memset
void MemSet(void* dst, int byte, int size)
{
char* end = (char*)dst + size, *p;
for(p = (char*)dst; p != end; *p++ = byte);
}
Si je mets les deux lignes en commentaire, rien
Si je laisse ces deux lignes: symbole externe non résolu _memset référencé dans la fonction _MemSet
Je n'ai pas de ZeroMemory ou autre choses du genre ailleurs dans mon code
Je trouve que le compilo prend vraiment trop libertés!
Je sais pas ce qu'a fait le compilo comme optimisation, c'est bizarre
Mais ta fonction bnzeromem est fausse, car en l'occurence avec une zone de 48 octets elle va boucler:
len >>= 3 donne 6, ensuite len -= 8 ne vaudra jamais 0
J'oubliais de préciser qu'ainsi on obtient un exe de 2 Ko.
Je remets le proj ici:
http://bnmvp.free.fr/nocrt.zip ça permettra de vérifier les options de compilo et linker.
Ce que je pense être le mieux si on ne veut pas de CRT et surtout ne pas sacrifier la vitesse (tout de même le + important).
WNDCLASSEX wc={0}; comme vu + haut, provoque un appel memset, exclus puisque non inline.
RtlZeroMemory(&wc, sizeof(WNDCLASSEX)); compilo remplace par memset, idem exclus.
bnzeromem(&wc, sizeof(WNDCLASSEX)); incroyable, le compilo a mis 2 affectations de 4 octets et fini, mystère complet. Espérons que ne se produira pas dans un vrai prog complet, à vérifier.
Voila tout ce qu'il en reste, histoire de fou:
@bnzeromem@8 PROC
; _pmem$ = eax
$mem8SET$77844:
mov DWORD PTR [eax], 0
mov DWORD PTR [eax+4], 0
$prepm1SET$77843:
$zeromemEXIT$77849:
ret 0
@bnzeromem@8 ENDP
En forçant une valeur "aléatoire" (GetTickCount), alors là NICKEL !!!
Passage correct en registres, tout se fait dans les 3 registres généraux donc pas de 'push pop', pas 1 cycle de perdu, parfait.
@bnzeromem@8 PROC
; _pmem$ = eax
; _len$ = ecx
; 20 : BYTE *p = (BYTE*) pmem;
; 21 : DWORD r = len;
mov edx, ecx
; 22 : if(!(len >>= 3)) goto prepm1SET;
shr ecx, 3
je SHORT $prepm1SET$77843
npad 9
$mem8SET$77844:
mov DWORD PTR [eax], 0
mov DWORD PTR [eax+4], 0
add eax, 8
sub ecx, 8
jne SHORT $mem8SET$77844
$prepm1SET$77843:
; 29 : if(!(r &= 7)) goto zeromemEXIT;
and edx, 7
je SHORT $zeromemEXIT$77849
npad 6
$mem1SET$77850:
; 30 : mem1SET:
mov BYTE PTR [eax], 0
add eax, 1
; 32 : if(--r) goto mem1SET;
sub edx, 1
jne SHORT $mem1SET$77850
$zeromemEXIT$77849:
ret 0
@bnzeromem@8 ENDP
Qu'il est bien ce compilo quand il ne nout fait pas des trucs à l'insu de notre plein gré...
Brunews >> J'aimerais bien avoir ton avis aussi sur le petit projet que j'ai envoyé à vecchio56. C'est une méthode de contrôle total sur les dépendances. Le compilo ignore totalement la CRT et le linker affiche le nom de toute fonction tentant d'y accéder. Si ça t'intéresse, laisse une adresse émail par MP.
mov eax, adresse
mov ecx, 44
memZERO:
mov dword ptr[eax], 0
add eax, 4
sub ecx, 4
jnz short memZERO
Changerait quoi qu'on mette 40 ou plus dans ECX ???
Même pas de problème d'alignement puisque le compilo aura par force placé correctement une struct, donc aucun besoin de code de controle préalable.
Ce code pourrait se mettre fort bien direct inline en place d'un appel de fonction.
Un compilo reste un compilo, rassurant pour le codeur manuel...
J'ai envoyé le projet.
Certes le fichier police est utile, mais un autre de moindre taille sera aussi utile puisque cette police ne sert qu'à démontrer le fonctionnement d'une fonction. Ce serait préférable de choisir un fichier plus petit. Ainsi on gagnera en taille de l'exécutable et en occupation mémoire. C'est mon point de vue.
Diminuer la taille de l'exe pour moi c'est surtout enlever tout ce qui est inutile. Ici le fichier police est utile donc pas de problème.
Je veux bien voir ton projet
Ce code est fait pour Visual C Express 2005. Ca doit être pareil avec la version complète car il utilise le même compilo et linker.
J'ai donné le code pour répondre à ta question sur comment je sais que c'est que c'est _memset qui manque. Avec ce code, le linker affiche:
error LNK2001: unresolved external symbol _memset
Si ça t'interesse, je peux t'envoyer le petit projet complet. Avec cette méthode, on est sûr qu'aucune fonction de la CRT n'est ajouté à notre exe.
A propos des 100ko, puisque tu cherches à diminuer la taille de l'exe en mettant ton point d'entrée, pourquoi ne pas choisir une police plus petite et gagner encore des dizaines de ko?
Dans le cas de WNDCLASSEX on peut juste mettre les autres membres à 0 et virer memset(). Ca permet de gagner 3Ko. Sans la ressource, l'exe ne ferait pas plus de 3ko.
Pourquoi ne pas choisir une police d'une dizaine de Ko?
Oui, tu as raison. Je viens de le voir. C'est plutôt à cause de ces 4 octets de plus de WNDCLASSEX. RegisterClassEx() n'a rien à voir là dedans. Je préfère comme ça car c'était la 1ère fois que je soupçonais une API.
Comme j'ai dit plus haut, c'est seulement du au fait que sizeof(WNDCLASSEX)>sizeof(WNDCLASSEX), et qu'a partir d'une certaine taille, memset n'est plus inlinée (sinon ca ferait du code trop gros)
Bonjour,
Chez moi le warning apparait avec RegisterClassEx(), seule ou avec memset().
A propos de RegisterClassEx(), je suis tout à fait d'accord. Si elle appelle _memset(), ça doit être en dehors de notre prog.
Personnellement, quand je veux que mon exe soit le plus petit possibe, je mets le code en C, je mets l'option /NODEFAULTLIB pour le linker et /GS- pour le compilateur. Je fouris dans le code la fonction d'entrée WinMainCRTStartup(). Un jour, en étant sûr que mon code ne fait aucun appel à la CRT, je me retrouve devant des erreurs indiquant les fonctions de la CRT manquantes. J'ai alors mis en commentaire tout le code sauf la WinMain(). Et là je découvre qu'avec RegisterClassEx() le linker demande _memset(). En la remplaçant par RegisterClass(), l'erreur diparait et l'exe est généré.
Dans le post suivant, je mettrai un petit exemple de code à tester.
En effet plus de warning avec RegisterClassEx (en fait je pensais que le warning était présent dès lors qu'on personnalisait le point d'entrée). Comment sais-tu que c'est memset qui est appelée par RegisterClassEx?
De toutes facons je comprends pas: le code de RegisterClassEx est situé dans user32.dll, et donc même si cette api utilise la CRT, ce devrait être indépendant de notre programme, non?
Il s'agit de msvcr80.dll et non msvcrt.dll. Désolé pour l'erreur.
vecchio56 >> Je viens de compiler ton projet tel quel sans rien changer. Au linkage j'ai deux warnings du genre:
warning LNK4210: .CRT section exists; there may be unhandled static initializers or terminators
Ca prouve bien qu'il y'a de la dépendance à la CRT. Pourtant, Depends n'affiche aucune dépendance. En remplaçant WNDCLASSEX par WNDCLASS et RegisterClassEx() par RegisterClass() les warnings disparaissent et la taille de l'exe descend à 100ko. Ca veut dire que RegisterClassEx() provoque implicitement l'ajout du code de _memeset à l'exéutable. C'est vrai qu'on se demande pouquoi cette API appellerait _memset().
vecchio56 >> Avec WNDCLASSEX wcex={0} la taille de l'exe est plus petite car memset() ajoute beaucoup plus d'octets. J'avais déja fait des tests. Je parle bien sûr d'un exe autonome sans aucune dépendance.
brunews >> C'est justement à cause de cette msvcrt80.dll que j'ai découvert tout cela. Cette dll n'est pas présente sur tous les ordinateurs et cela nous oblige à la lier statiquement dans le programme. Même en virant toute référence à la CRT, mes programmes en dépendent toujours à cause de certaines APIs. RegisterClassEx() n'est pas la seule car j'ai remarqué le même comportement avec d'autres. J'ai l'intention de les répertorier et essayer de faire un tutorial à ce sujet.
Mais le + fort, je viens de comparer les options linker et compilo de ton proj avec le mien, exactement les mêmes.
S'il y a de l'alea dans le binaire maintenant, tout est perdu...
OK pour le FreeResource, je regarderai cela
WNDCLASSEX wcex={0}; va sans doute générer un fichier plus gros, il signifie en fait WNDCLASSEX wcex={0, 0, 0, ..., 0}; (cela dit ta solution diminue la taille du fichier source)
RegisterClassEx est une fonction, donc son appel est traduit par un call, rien de plus
Heureusement d'ailleurs, pourquoi ferait-elle un memset? Elle pourrait plus lire les infos dans la structure
C'est fou cette histoire, l'autre jour je me suis retrouvé avec un exe lié à msvcrt8.dll pour cause que l'exe appelait _memset et _memcpy sur cette dll. J'ai viré la dépendance en fournissant mes funcs au lieu des 2 originalez.
Faut dire que c'était la 1ere fois que je notais cela et l'exe de vecchio non plus n'a pas de dépendance.
Je note pourtant le
call _memset
dans l'asm produit par le compilo.
Mystique tout cela, sera à approfondir.
Je pense que non vecchio56, RemoveFontMemResourceEx() ne doit pas être appelée aussitôt. Je viens de tester. La police ne sera plus disponible et sera remplacée par la police par défaut. Moi je parlais de FreeResource():
- Charger la ressource avec LoadResource().
- Appeler AddFontMemResourceEx()
- Libérer la ressouce avec FreeResource().
- Créer la police.
D'après mes tests, RemoveFontMemResourceEx() ne doit être appelée que si on n'aura plus besoin de notre police. Elle fera donc suite à DeleteObject(hPolice)
Puisque tu cherchais à diminuer la taille de l'exe, pourquoi ne pas virer memset()?
WNDCLASSEX wcex={0}; serait suffisant.
Il est à noter que l'API RegisterClassEx() fait implicitement appel à memset() et fait donc augmenter la taille de l'exe. RegisterClass() quant à elle ne fait pas d'appel à la CRT. J'ai découvert tout ça dernièrement. Tu peux faire des tests pour en avoir le coeur net.
Oui pour le RemoveFontMemResourceEx j'ai vu qu'on peut l'appeler aussitot, le HFONT n'en a pas besoin.
Pour l'option: si, elle diminue la taille de l'exécutable ici (103Ko au lieu de 134Ko avec WinMain)
Salut,
Merci vecchio56 pour ce code. Je viens de me servir de la fonction AddFontMemResourceEx() dans mon dernier code source déposé il y'a un instant. Cette fonction m'a servi à ajouter une police au système à partir d'une ressource en mémoire. Je viens de remarquer qu'une fois la police ajoutée, la ressource peut être libérée sans problème. Donc un appel de FreeResource() juste après AddFontMemResourceEx() serait préférable.
A propos du #pragma comment(linker, "/entry:myWinMain"), je ne crois pas qu'il soit d'une grande utilité dans ton code. Car même si le point d'entrée du programme évite l'utilisation de la CRT, cette dernière sera de toute façon utilisée dans ton programme. memset() par exemple. Et la taille de l'exe ne sera pas réduite.
Y'a-t-il une autre raison de l'utilisation de cette option du linker?
Merci.
- Messages postés
-
21042
- Date d'inscription
- jeudi 23 janvier 2003
- Statut
- Modérateur
- Dernière intervention
- 21 août 2019
27C'est visible ici:
r = ((DWORD) p) & 3;
*((DWORD*) p) = 0;
*((DWORD*) (p + 4)) = 0;
J'avais un autre message quand j'avais mis "Ignore All Default Libraries" à yes :
error LNK2001: unresolved external symbol __chkstk
Pour ceux qui l'ont eu c'est à cause d'un buffer trop gros, j'en avait un a 768 WCHAR je l'ai descendu a 256 et plus de message même avec cette option activée.
- Messages postés
-
21042
- Date d'inscription
- jeudi 23 janvier 2003
- Statut
- Modérateur
- Dernière intervention
- 21 août 2019
27Je viens d'ajouter ceci (entre autre) dans mon taf en cours:
JJ = pcurrArts->dateF - pPLAN[0];
if(JJ < 0) JJ = 0;
for(; JJ < NCOLS; JJ++) TPLANAR.jours[JJ] = 0;
ben il m'a remplacé la boucle par un: call memset
pénible...