vecteurs libres - Page 1

Je suis en train de bosser sur une fonction d'effacement de TSR qui a besoin de stocker 2 variables (8o) à une adresse constante. Y-a-t-il un endroit de la RAM non utilisé (je pense aux derniers vecteurs d'interruptions inutilisés) où je pourrais stocker ces variables ? Je sais que je pourrais les enregistrer en PC-relative, mais cela m'oblige à recopier le code en RAM si jamais il est exécuté en archive, donc j'ai pas envie (faudrait que j'alloue un handle, que je le verrouille, que je le déréférence...)

Bah oui mais imagine qu'un autre gros malin ait la même idée et utilise la même adresse ?

je sais bien, mais bon... ça me soûle de grossir mon prog pour seulement 8o. Y a pas d'autre méthode sinon ?

Tu peux utiliser la pile?

non, le but c'est de sauver le pointeur de pile, justement. si je le sauve sur la pile, je sais pas si c'est très utile...

lol, s'était pas précisé.

Je pense que tu es obligé de faire un handle... D'un autre côté 8 octets c'est pas énorme.

mais si je fais le handle, je dois recopier tout le code de suppression de TSR dedans pour pouvoir utiliser des instructions pc-relative quand je veux récupérer mon pointeur de pile, ça fait au moins 200 d'octets je pense, voir plus (le code de suppression est pas très beau). c'est pour ça que réserver 2 vecteurs juste le temps de qqes instructions, ça m'aurait bien arrangé

C'est pour faire un truc du style le exit de TIGCC, mais pour la désinstallation de hooks d'évènements. (Il m'a envoyé son code pour que j'y jette un coup d'œil.)

Personnellement, je ferais quelque chose du style les trampolines de GCC pour résoudre ton problème: copier en RAM juste le minimum de code pour mettre les variables sauvegardées dans des registres et sauter vers le reste du code (en ROM).

Et je te signale aussi que tu ne devrais pas te casser la tête à garder d0-d2/a0-a1 intacts, ces registres sont faits pour être détruits par les fonctions, donc tsr_delete a tout à fait le droit de les détruire (et celui de UnInEvHk 3.00 le fera probablement). Dans ton code, il suffit de sauvegarder/restaurer d3-d7/a2-a6. Utiliser ces registres sans les sauvegarder/restaurer pourrait certainement t'arranger pour la solution du trampoline. Le trampoline pourrait passer des variables au code en ROM à travers a0, a1, d1 et d2.

tsr_delete fait partie d'un programme qui ne respecte pas forcément ces conventions. C'est pour ça que je préfère sauvegarder tous les registres. Ca bouffe un peu de pile mais ça n'augmente pas la taille du code.

Pour le coup des trampolines, je vais y réfléchir, ça doit pouvoir se faire sans trop de difficultés.

Flanker
: tsr_delete fait partie d'un programme qui ne respecte pas forcément ces conventions. C'est pour ça que je préfère sauvegarder tous les registres. Ca bouffe un peu de pile mais ça n'augmente pas la taille du code.

OK, je voulais surtout te rappeler de suivre la convention d'appel dans les hooks pour éviter de potentiels ennuis plus tard. Sauvegarder des registres en plus ne pose pas de problèmes en lui-même.

Pour le coup des trampolines, je vais y réfléchir, ça doit pouvoir se faire sans trop de difficultés.

Oui. Mais comme déjà dit, il faudra probablement détruire au moins un registre pour le passage des arguments.

je vais y réfléchir.
Quand est-ce qu'une version définitive du nouveau standard de TSR serait prête ? Maintenant que le code d'effacement est prêt, j'aimerais pouvoir sortir mes tsr qui l'utilisent

Je vais voir ça ce weekend. (J'espère que je n'oublierai pas.)
Avec tout le travail sur TIGCC, je n'ai plus beaucoup de temps pour tout ce qui est hooks d'évènements.

ok, merci