écrire un gestionnaire d'interruption - Page 1

sr,-(a7) move.l gray_function,-(a7) rts clavier_natif_handler_1_suite: move.l save_int_1,-(a7) rts

J'ai oublié beaucoup de choses avec le temps et je ne comprends plus ce code dans les sources d'Einstein 3.1 :clavier_natif_handler_1:
	pea		clavier_natif_handler_1_suite(pc)
	move	

Pourquoi faut-il pousser le registre de statuts ? Pourquoi je poussais les adresses des fonctions avant de faire un RTS ? il ne suffit pas d'un JMP ?

Ce code est appelé par la première interruption automatique. Il est sensé lancer la routine d'affichage en niveaux de gris, puis la routine d'AMS qui est associée à l'int 1 en temps normal (car grayon est appelé après avoir rempalcé l'int 1 par un DUMMY_HANDLER, donc je dois la lancer manuellement).

Pourquoi ça plante ?

Regarde les différences entre les instructions RTE et RTS.

Je vais chercher ça dans mes vieux classeurs...

Thibaut (./1) :
Pourquoi faut-il pousser le registre de statuts ?

Parce que la grayint fait un rte et pas un rts.

Thibaut (./1) :
Pourquoi je poussais les adresses des fonctions avant de faire un RTS ?

Pour faire un saut de fonction.

Thibaut (./1) :
il ne suffit pas d'un JMP ?

pour ne pas détruire de registre.

C'est bon, ça ne plante plus. Le problème venait du code C (erreur d'inattention : confusion entre pointeurs et valeurs), pas de cette routine ASM.

Ouai je veux bien, mais comment feront les gens qui voudront porter tes programmes sur Nspire ? Ou sur toute autre plateforme ? C'est pas évident à recompiler pour une autre machine, un code ASM....

Je pense que dans le programme TIGCC (ou GTC, ça ne change rien sur ce point-là ) moyen, il y a tellement de trucs spécifiques à la plateforme de toute façon que ce n'est pas portable quoi qu'on fasse.

Ben si je prends l'exemple d'Einstein (parceque je le connais bien pour en parler), le plus gros du code ne dépend pas de la plateforme. Il n'y a que les routines d'affichage (sprites, texte) et les macros de lecture du clavier (rowread rapide) qui sont à changer pour le porter. Et, évidemment, remplacer les appels à l'AMS par leur équivalent sur la plateforme visée.
Toutes ces modifications ne concernent que 30% du code je pense. C'est mieux que les 100% d'un programme ASM

Martial Demolins (./12) :
Nan, suffit de faire un ému.

C'est ce que j'allais dire. Emuler du 10 MHz avec un ARM9 ça pose aucun pb ! ^^

Je doute qu'un émulateur soit plus simple à faire que le portage d'un code C !

Martial Demolins (./12) :
(t'as sûrement tout prévu pour les nested folders hein )

Eh bien oui Il suffit de changer une constante dans le fichier global_definitions.h et hop, magie, la quasi totalité des fonctions deviennent compatibles avec un système de fichier récursif Je passe par une FAT virtuelle, et presque toutes les fonctions travaillent dessus. Ca permet d'avoir un code indépendant de la plateforme. Il suffit de modifier la fonction qui génère la FAT virtuelle à partir de la FAT réelle pour que le reste du programme soit capable de travailler sur la plateforme visée.
mmmh... tu fais toujours ton malin ou c'est bon ?

Quoi qu'il en soit avant de parler d'émulation ou de portage sur Nspire, il faudrait avant tout pouvoir executer du code dessus. Ca s'est un autre problème !

Oui c'est sûr...

Ah mais il pense ce qu'il veut ! Qu'est-ce que ça peut me faire ?

C'est toi qui voulait Einstein sur Titanium ? Si tu veux une version qui marche je peux t'envoyer ça, mais fait attention, y'a des plantages sévères. Tu ne pourras que lancer les programmes et lire des textes et des images. Le couper/copier/coller plante. Le renommage de fichiers marche (enfin) mais pas celui des répertoires qui va te donner un big address error.

J'ai pas dit qu'elle bug sur Tta J'ai dit qu'elle tourne sur Tita. Ca bug partout

Mais je pense avoir trouvé la cause. Je supposais que strncpy(DossierCible, name, 8) plaçait toujours un zéro à la fin de DossierCible. Après avoir pas mal tourné en rond, j'ai eu un doute sur le fonctionnement de strncpy. Et, en effet, cette fonction ne termine pas la chaîne par un zéro si name comporte 8 caractères ou plus !
C'est hallucinant pour une fonction qui traite des chaînes ! Les chaînes doivent toujours se terminer par zéro, par définition.

Pourquoi les créateurs de la librairie standard du C ont-ils implémenté strncpy comme ça

Oui mais pourquoi ? Je ne comprends pas, dans la mesure où toute chaîne de caractères doit être terminée par un zéro en C.

Thibaut (./24) :
Oui mais pourquoi ? Je ne comprends pas, dans la mesure où toute chaîne de caractères doit être terminée par un zéro en C.

Aucune idée.
Ca et le manque d'expressivité des qualifier sont les grosses lacunes du C.

C'est chiant parceque ce détail complique et grossit le code. Il faut rajouter soi-même le zéro. K&R devaient être fatigués ce jour là.

Why does strncpy not always place a '\0' termination in the destination string?

strncpy was first designed to handle a now-obsolete data structure, the fixed-length, not-necessarily-\0-terminated "string." strncpy is admittedly a bit cumbersome to use in other contexts, since you must often append a '\0' to the destination string by hand.

http://www.lysator.liu.se/c/c-faq/c-12.html

Thibaut (./27) :
C'est chiant parceque ce détail complique et grossit le code. Il faut rajouter soi-même le zéro. K&R devaient être fatigués ce jour là.

implémente un wrapper, c'est le plus simple

Cette structure de données n'est pas si obsolète que ça étant donné que c'est ce qu'utilise la VAT. Et les formats TI-GraphLink aussi. (Enfin, dans le cas de la VAT, l'octet qui suit est censé toujours être 0, dans le cas des format TI-GraphLink sur PC pas forcément.)