Index » Forum Ti 89, Titanium / 92+ / Voyage 200 et TI-Nspire » Prog C TI (398r) » Librairie dynamique Le problème dans tout ça c que si jamais quelque chose (coupure de courant, programme qui plante, os qui plante, …) foire au milieu de la modification du fichier, y'a un fort risque qu'une partie (au moins) des données soit perdue. Bon, y'a quand même un moyen pas trop tordu ni compliqué pour sécuriser ça mais il faut y penser   Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin. T'as un problème ? Tu veux un bonbon ? [CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes |
Même si c'était dans la libc, ce ne serait quand-même pas garanti atomique (même fwrite ne l'est pas). |
(merde, j'aurais dû préciser dans la partie de "la libc portée sur TI"  ) "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Sur TI, la méthode du mmap n'est pas mal, sauf que tu utilises les fonctions de vat.h pour avoir accès à l'adresse des données, pas mmap. (Et c'est probablement la plateforme où memmove est plus efficace qu'une copie par blocs. Enfin, probablement aussi pour un ramdisk GNU/Linux, remarque. L'idée, c'est que le fichier est en RAM, du coup memmove est adapté.) |
Ah mais il n'a pas dit que le fichier n'était pas archivé, hein  — Zeroblog — « Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau |
Bah, alors il doit le désarchiver d'abord s'il veut y écrire, évidemment. |
En fait, je cherchais une solution 100% portable  "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
je crois que tu vas avoir du mal sans réécrire le fichier à coté avant de supprimer l'ancien (ce qui demande le double de mémoire, oui oui)  For most people, good enough is near enough. For the few, good enough is never enough. Nspire wiki CONDUCTEUR Va-et-vient Des QUATRE MANCHE AVEC DES DIODES |
J'en étais arrivé à cette conclusion, tout en me disant "aller, ya bien un truc que j'ai pas du voir" "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
La boucle de fwrite et fread pour déplacer le contenu du fichier est 100% portable. |
Bon, ya une manière de faire de gcc que je ne comprends pas du tout... J'ai une fonction C : /** CompareStrings
*
* Check if the string RefString terminated by a char of SeparatorTable is contained in the string table StringTable
* Return #item in the table, or -1 if the string isn't in the table. First item is #0
* Put in *NextChar a ptr to the next char after RefString if NextChar != NULL
**/
short CompareStrings(const char **NextChar, const char *RefString, const char *StringTable, const char *SeparatorTable)
{
// TODO
// This function could be optimized a lot, comparing char by char the two strings,
// and checking SeparatorTable if they match and *StringTable == 0.
// Here the StringTable is read twice, which is not optimal, but it's easier to write.
const char *EndChar;
const char *Separator;
short Item = 0;
unsigned long length;
while (*StringTable)
{
length = strlen(StringTable);
if (!strncmp(RefString, StringTable, length))
{
EndChar = RefString + length;
Separator = SeparatorTable;
do
{
if (*Separator == *EndChar)
{
if (NextChar != NULL)
*NextChar = EndChar;
return Item;
}
} while (*Separator++);
}
StringTable += length + 1;
Item++;
}
return -1;
}qui donne ça en assembleur : movm.l #0x1e30,-(%sp) move.l 28(%sp),%a3 move.l 32(%sp),%d5 move.l 36(%sp),%a2 move.l 40(%sp),%d6 clr.w %d4 jbra .L2 .L3: move.l %a2,-(%sp) jsr _ROM_CALL_27E:l move.l %d0,%d3 move.l %d0,-(%sp) move.l %a2,-(%sp) move.l %d5,-(%sp) jsr _ROM_CALL_272:l lea (16,%sp),%sp tst.w %d0 jbne .L4 move.l %d5,%a1 add.l %d3,%a1 move.b (%a1),%d1 move.l %d6,%a0 .L6: move.b (%a0),%d0 cmp.b %d0,%d1 jbne .L7 cmp.w #0,%a3 jbeq .L15 move.l %a1,(%a3) .L15: move.w %d4,%d0 jbra .L11 .L7: tst.b %d0 jbeq .L4 addq.l #1,%a0 jbra .L6 .L4: lea 1(%a2,%d3.l),%a2 addq.w #1,%d4 .L2: tst.b (%a2) jbne .L3 moveq #-1,%d0 .L11: movm.l (%sp)+,#0xc78 rts Comme on peut voir, le if (NextChar != NULL) est traduit en cmp.w #0,%a3 Pourquoi un cmp.w ? Si l'adresse que je passe pointe vers $10000, ça fait quoi ? Alors qu'un move.l %a3,%d0 eût été plus petit (-2 octets), et peut-être plus rapide  Là, j'avoue que je capte pas du tout... (tout le reste me semble bien compilé) "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
C’est interdit de regarder sous le capot Edité par Sasume le 28-02-2010 à 00:50:08. Il me semble que dans l’instruction cmp.w #0, %a3, le .w ne porte que sur la première opérande, la valeur immédiate #0, valeur qui sera étendue sur 32 bits avant d’être comparée à la valeur du registre a3  Donc tout va bien ! (sinon pourquoi tu mixes lowerCamelCase et UpperCamelCase dans tes noms de variables ? Perso je préfère une convention différente pour les noms de variables et de fonctions, pour les différencier au premier coup d’œil)  « Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. » |
Ah merci, une fois sur deux quand je rate un truc c'est que j'oublie l'extension... Edité par Folco le 28-02-2010 à 01:02:53.N'empêche que niveau place, c'est pas optimal... "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Pas sûr. Un move.l %a3, %d0 écraserait le registre %d0, peut-être qu’il est utilisé (j’ai pas regardé le code) ? « Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. » |
Non, ça ne changerait rien, on écrase %d0.w deux lignes plus loin, c'est la valeur de retour. Edité par Folco le 28-02-2010 à 01:02:10.Sasume (./370) : Bien vu, une erreur "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Ouais enfin, on peut faire tst.l %a3 aussi. cmp.w, c'est naze pour le coup. EDIT : cross — Zeroblog — « Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau |
Tiens d'ailleurs, le while (*Separator++); prend 8 octets de plus que while (*Separator); Je sais pas comment il se démerde là encore, un simple addq... J'ai pas regardé le code, mais de toute façon ça m'épate méchamment... "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Zerosquare (./374) : Non, marche pas sur les an. ADDRESSMETHODS: Dn, (An), (An)+, -(An), x(An), x(An,xr.s), x.w, x.l (68kguide) D'ailleurs des fois c'est bien chiant, mais j'utilise toujours un move.l an,dn, c'est le plus court/rapide que j'ai trouvé "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Exact, mea culpa. — Zeroblog — « Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau |
Il vaut mieux éviter de regarder le code produit par GCC si on est sensible à ce genre de choses.  |
Concrètement ça veut dire quoi ? GCC n'est pas un bon compilo ? J'ai l'impression qu'il lui faut une optimisation pipole tous les deusx lignes... "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
GCC est plutôt parmi les bons compilos, mais comme il accepte plusieurs langages source en entrée et plein de plate-formes en sortie, et qu'il manque de flexibilité (la version 4.5, pas encore releasée, améliore ce deuxième point), il ne peut clairement pas être aussi bon que les compilos spécifiques à une plate-forme. Le compilo d'Intel est meilleur que GCC pour les x86 Intel, le compilo d'ARM est meilleur que GCC pour les ARM, etc.  Membre de la TI-Chess Team. Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP. |
C'est aussi surtout que le backend 68k n'est pas super bien maintenue. Lionel Debroux (./380) : Vrai sur X86. Faux sur AMD64: http://multimedia.cx/eggs/64-bit-gcc-icc-performance-round/ http://multimedia.cx/eggs/last-performance-smackdown-for-awhile/ http://multimedia.cx/eggs/compiler-smackdown-2010-1-64-bit/ Il semblerait que ICC en 64 bits soit assez loin de ce que faisait son petit frère. |
En effet, on voit clairement que les playmate GCC y sont pour quelque chose  "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Je ne connaissais pas ce benchmark. En 32 bits, c'est amusant que LLVM, projet beaucoup plus récent (mais avec une architecture plus moderne...) que GCC, arrive à faire mieux que GCC. Il fait d'ailleurs également mieux que les ICC récents... ./382: ttk Membre de la TI-Chess Team. Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP. |
Lionel Debroux (./383) : Je n'ai pas vu de bench sur llvm en 32 bits. Juste en 64 bits. Mais j'avoue que j'ai étais surpris de ces résultats. Mon expérience personnelle n'est pas plutôt bonne à son sujet. |
J'ai écrit cette fonction : Edité par Folco le 02-03-2010 à 13:42:49./** SkipSpaces
*
* Skip spaces and horizontal tabs. Return a pointer to the next non-space char, or to EOF
*/
const char *SkipSpaces(const char *Ptr)
{
while (*Ptr && (*Ptr != EOL) && ((*Ptr++ == SPACE) || (*Ptr == HTAB)));
return Ptr;
}Est-ce que ça va bien passer tous les espaces/htab et pointer sur le premier caractère suivant ? Et renvoyer un pointeur sur un caractère nul ou EOL si on y arrive ? Parce que pour moi ça marche tel que c'est, sauf si le compilateur s'amuse à inverser l'ordre des conditions. J'aimerais savoir si une implémentation peut mettre ce code au tapis. J'utilise cette écriture parce que je gagne deux octets par rapport à une écriture plus naïve. Je vous emmerde.  "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
&& et || sont des sequence points, donc ton code est valide. (C'est un des rares cas où tu peux faire ça à l'intérieur d'une expression.) Mais il est faux quand-même. Tu testes le mauvais caractère pour HTAB. De plus, ton *Ptr && est redondant, si le caractère est \0, ce n'est ni un espace, ni un tab. Edité par Kevin Kofler le 02-03-2010 à 13:44:43.EDIT: J'ai écrit ça avant que tu as ajouté "(*Ptr != EOL) &". Il manque un & là et c'est aussi une condition redondante pour la même raison pour laquelle *Ptr est redondant. |
Ah, donc le ++ est fait avant le (*Ptr == HTAB) ? Je pensais qu'il était fait à la fin de l'évaluation complète de la condition dans son ensemble Edité par Folco le 02-03-2010 à 13:46:02. Et ok pour le *Ptr, j'ai changé mon écriture et je l'ai oublié Donc au final ça donne ça pour moi : while ((*Ptr != EOL) && ((*Ptr++ == SPACE) || (*Ptr == HTAB))); "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Folco (./387) : Oui, il est fait avant le prochain sequence point, qui est ||. |
Kevin Kofler (./388) : Erf zut... (sinon oui, j'ai multi-cross-édité) "MSVC, le soft qui arrive à générer des problèmes à partir de solutions" © |
Index » Forum Ti 89, Titanium / 92+ / Voyage 200 et TI-Nspire » Prog C TI (398r) » Librairie dynamique 
Ouvrir dans une nouvelle fenêtre
Pages 
Mes news pour calculatrices TI: 
