360

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 sorry
avatar
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

361

Même si c'était dans la libc, ce ne serait quand-même pas garanti atomique (même fwrite ne l'est pas).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

362

(merde, j'aurais dû préciser dans la partie de "la libc portée sur TI" grin)

363

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é.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

364

Ah mais il n'a pas dit que le fichier n'était pas archivé, hein grin
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

365

Bah, alors il doit le désarchiver d'abord s'il veut y écrire, évidemment.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

366

En fait, je cherchais une solution 100% portable cheeky

367

je crois que tu vas avoir du mal sans réécrire le fichier à coté avant de supprimer l'ancien cheeky (ce qui demande le double de mémoire, oui oui)

368

J'en étais arrivé à cette conclusion, tout en me disant "aller, ya bien un truc que j'ai pas du voir" grin

369

La boucle de fwrite et fread pour déplacer le contenu du fichier est 100% portable.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

370

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 :
[source=plain] 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[/source]
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 confus
Là, j'avoue que je capte pas du tout... (tout le reste me semble bien compilé)

371

C’est interdit de regarder sous le capot embarrassed
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 smile
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)
avatar
« 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. »

372

Ah merci, une fois sur deux quand je rate un truc c'est que j'oublie l'extension...
N'empêche que niveau place, c'est pas optimal...

373

Pas sûr. Un move.l %a3, %d0 écraserait le registre %d0, peut-être qu’il est utilisé (j’ai pas regardé le code) ?
avatar
« 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. »

374

Non, ça ne changerait rien, on écrase %d0.w deux lignes plus loin, c'est la valeur de retour.
Sasume (./371) :
(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)

Bien vu, une erreur grin

375

Ouais enfin, on peut faire tst.l %a3 aussi. cmp.w, c'est naze pour le coup.

EDIT : cross
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

376

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...

377

Zerosquare (./375) :
Ouais enfin, on peut faire tst.l %a3 aussi. cmp.w, c'est naze pour le coup.

EDIT : cross

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é

378

Exact, mea culpa.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

379

Il vaut mieux éviter de regarder le code produit par GCC si on est sensible à ce genre de choses. gni
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

380

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...

381

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.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

382

C'est aussi surtout que le backend 68k n'est pas super bien maintenue.
Lionel Debroux (./381) :
Le compilo d'Intel est meilleur que GCC pour les x86 Intel.

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.

383

En effet, on voit clairement que les playmate GCC y sont pour quelque chose trioui

384

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...

./383: ttk grin
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

385

Lionel Debroux (./384) :
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...


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.

386

J'ai écrit cette fonction :/** 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. smile

J'utilise cette écriture parce que je gagne deux octets par rapport à une écriture plus naïve. Je vous emmerde. tongue

387

&& 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: 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.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

388

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 sad 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)));

389

Folco (./388) :
Ah, donc le ++ est fait avant le (*Ptr == HTAB) ?

Oui, il est fait avant le prochain sequence point, qui est ||.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

390

Kevin Kofler (./389) :
Oui, il est fait avant le prochain sequence point, qui est ||.

Erf zut... (sinon oui, j'ai multi-cross-édité)