SET_FILE_IN_USE_BIT - Page 1

J'ai lu la doc de TIGCC, mais j'ai pas trop compris à quoi ça sert, mais ça a l'air intéressant. Si quelqun pourrait m'expliquer à quoi ça sert, ce serait cool...

À éviter que ton programme plante si tu utilises le "event loop" de AMS. (C'est un bogue de AMS. )

"C'est un bogue de AMS"
Vite dit. Je pencherais plutôt pour une limitation volontaire made in TI, ou à la limite qqch non implémenté. En tout cas qd on voit le code de démarrage d'un prog ASM on voit qu'ils ont pensé au pb.

Pollux
: qd on voit le code de démarrage d'un prog ASM on voit qu'ils ont pensé au pb.

Que font ils ?

Dans EM_twinSymFromExtMem :
twins_to_cleanup=1;
Dans l'event loop :
if (twins_to_cleanup) TwinsCleanup(),twins_cleanup=0;

Et enfin :

...
HSym hs=FindProgram();
void *run=Relocate(hs);
ASM_call(run);
if (DerefSym(hs)->flags.bits.twin) twins_to_cleanup=1;
...

En gros, on a bien l'impression qu'ils ont oublié de rajouter une fonction "twins_to_cleanup=0", ou bien qu'ils ont oublié de mettre le file in-use bit. Enfin dans tous les cas le fait de garder le HSym tel quel pose problème (création de variables), ce qui explique probablement le fait qu'ils n'aient pas rajouté le support des dialogues pour les progs ASM. Et comme ils ne voulaient certainement pas activer 'twins_to_cleanup' à chaque fois (encore que on se demande si ça aurait changé grand chose, vu la lenteur des boîtes de dialogues ), ils ne l'ont pas fait dans le stub du programme. Evidemment, ils auraient mieux fait de prendre le problème à la base et d'implémenter ce genre de choses dans HeapAlloc (nettoyage des syms non utilisés), mais ça pose qd même problème puisque les twins sont lockés (déplacements indispensables à la fermeture du prog -> ralentissements avec flib/vertel, etc... alors qu'avec leur système de twin il n'y a pas ce genre de pb [sauf pour les shells basic ])

J'ai lu 2 fois. Et y'a toujours des trucs qui m'echappent. Tu peux reexpliquer

je confirme le gros pavé de pollux est incompréhensible :/

TU peut pas faire un poil plus clair stp ?

Ouf, ça vient pas de moi... sérieux, c'est un peu... confus.

Ben j'avais pas envie de rentrer trop dans les détails mais bon... En gros :
- lorsque la TI lance un prog archivé, elle crée un twin et active un flag 'twins_to_cleanup', pour signaler à l'event loop de nettoyer les twins qui ne sont pas 'in use' la prochaine fois qu'elle s'exécutera.
- donc tant que l'event loop n'est pas lancée, le twin n'est pas supprimé. Intéret : un prog en Basic qui utilise flib à chaque instruction n'a pas besoin de recopier le prog en RAM à chaque fois, meme s'il est archivé.
- problème : si un prog ASM lance l'event loop, gros problème : elle va supprimer le twin => crash
- d'où le fix "quick & dirty" de TIGCC qui active le flag "in use" du programme comme ça l'event loop ne le supprime pas, mais il y a un problème : twins_to_cleanup est remis à 0 par l'event loop, d'où un mémory leak jusqu'à la prochaine exécution d'un prog archivé qui, elle réactivera twins_to_cleanup
- heureusement, TI a été gentil et a rajouté une autre détection pour réactiver twins_to_cleanup ; mais il y a _toujours_ un problème : cette détection suppose que le HSym du programme reste constant, ce qui est complètement faux si le programme crée / supprime des fichiers.

Ce qui m'amène à penser que ce n'est pas un bug de la part de TI, mais plutot une omission plus ou moins volontaire, autrement dit : TI ne supporte probablement pas officiellement l'utilisation des boites de dialogues dans les progs ASM (c'est meme écrit noir sur blanc dans leur doc que les programmes RAM ne peuvent pas utiliser les événements et que c'est spécifique aux flashapps).

Mais s'ils avaient voulu réellement implémenter ça, il aurait suffi de rajouter une fonction SetFileInUseBit() au début du programme et une fonction EnableTwinsCleanup() à la fin. Autrement dit, propagande en faveur des FlashApps (comme la limite des 24k) ?

Ok, c'est un peu se qeu j'avais compris

oui on pourrait pencher sur ton point de vu effectivement,

Tu sais, vu le nombre de leaks qu'on peut trouver sur la TI 68k, c'est peut-être simplement qu'ils avaient la flemme ou qu'ils n'y ont pas pensé... sinon, ils ont vraiment l'esprit prevers.

Je crois plutot que c'est parce qu'il est possible que le programme asm ajoute des fichiers a la VAT, et qeu donc la HSym est modifie, et comme ils sont incapables de retourver le fichier, ils doivent tout scanner. Comme c'est lent, ils le font dasn l'event-loop.
Pas plus complique que ca, mon avis est.

Pollux, si tu nous donnes un moyen de trouver l'adresse de twins_to_cleanup (il faudra probablement un hack), je veux bien mettre quelques lignes de code pour la remettre à 1 à la fin dans les programmes utilisant SET_FILE_IN_USE_BIT.

Tu prends l'adresse de retour. Tu parcours un peu pour rechercher DerefSym (Soit par un bsr.w ou par un jsr).
Tu lis l'adresse qui se trouve quelques octets plus loin. Si tu trouves rien sur une taille raisonnable (256 octets ?), on ne fait rien.

Tu sais, vu le nombre de leaks qu'on peut trouver sur la TI 68k, c'est peut-être simplement qu'ils avaient la flemme ou qu'ils n'y ont pas pensé... sinon, ils ont vraiment l'esprit prevers.

Ce n'est pas une question d'esprit pervers. C'est plus probablement de la flemme ou une volonté de simplicité d'utilisation [dans leur mentalité, pourquoi rajouter des romcalls qui seront inutiles aux flashapps?], avec qd même une légère pointe de perversion (marquer dans la doc que c'est un avantage des FlashApps )

Je crois plutot que c'est parce qu'il est possible que le programme asm ajoute des fichiers a la VAT, et qeu donc la HSym est modifie, et comme ils sont incapables de retourver le fichier, ils doivent tout scanner. Comme c'est lent, ils le font dasn l'event-loop.

Oui, bien entendu. Je n'ai pas dit à un seul moment que c'était une mauvaise idée de mettre ça dans l'event loop, je dis juste qu'il manque un ROMCALL pour faire ça proprement.

Tu prends l'adresse de retour. Tu parcours un peu pour rechercher DerefSym (Soit par un bsr.w ou par un jsr). Tu lis l'adresse qui se trouve quelques octets plus loin. Si tu trouves rien sur une taille raisonnable (256 octets ?), on ne fait rien.

=> possibilité de problème avec certains launchers... C'est probablement bcp plus propre d'aller chercher l'adresse dans TwinSymFromExtMem.

Pollux, si tu nous donnes un moyen de trouver l'adresse de twins_to_cleanup (il faudra probablement un hack), je veux bien mettre quelques lignes de code pour la remettre à 1 à la fin dans les programmes utilisant SET_FILE_IN_USE_BIT.

J'ai vraiment la flemme et puis c franchement pas important (juste un léger memory leak temporaire)
Ce que je voulais dire était simplement que l'histoire du in_use_bit qui manque est loin d'être un bogue, et que les choses sont un peu plus compliquées que ça...

Mais non tu verifies que tu es bien dans la rom.

Oui, mais ça n'empêche qu'il y a tjs un risque de leak. Et surtout, le fait d'activer une variable globale TIOS à 1 ne veut pas forcément dire que c'est cette variable là qui est concernée (surtout si TI change la manière de gérer les twins...).

Un hack reste un hack

Oui Mais autant c'est stable d'activer le bit "in use", ça l'est bien moins de toucher à une variable interne...