encore une chtite question - Page 17

Parce que zguide décrit le tout à un niveau beaucoup trop bas...

L'instruction rts s'occupe elle-même de popper l'instruction de retour et d'y sauter.

Tu as dû mal lire. Il dit de bien dépiler les valeurs que tu as empilées toi-même, pas celles que le processur met, lui. Si tu es sûr de toi, cite le passage ?

Kevin Kofler :
Parce que zguide décrit le tout à un niveau beaucoup trop bas...

L'instruction rts s'occupe elle-même de popper l'instruction de retour et d'y sauter.

Oui j'avais oublié de préciser que c'était le rts/rte qui le faisait, c'était tellement implicite

Pour le var-link, tu peux faire la méthode gore : intercepter l'AI1 et rajouter à la fin un test qui regarde si la touche qui est dans le buffer est 2nd+"-", puis agir en conséquence, mais évidemment ça intercepte la combinaison n'importe où (y compris dans un prog ASM : pour éviter ça, tu peux tjs détecter si on est dans un prog ASM, mais alors l'interception ne sera plus infaillible : si le prog ASM ne lit pas ses touches, alors c'est le TIOS qui récupérera ça, et il pourra lancer le Var-link)...

Il y a aussi p-ê un truc à faire avec les événements (sauf que comme le var-link n'est pas une app, il n'y a pas forcément d'événement envoyé au démarrage, donc ce n'est p-ê pas possible)

Si tu veux un trucs un peu plus hardcore (mais plus fiable), tu peux t'arranger pour faire planter le var-link de manière propre en corrompant la VAT et en interceptant l'exception correspondante... Mais y a p-ê plus simple, hein, j'en sais rien.

Si tu veux un trucs un peu plus hardcore (mais plus fiable), tu peux t'arranger pour faire planter le var-link de manière propre en corrompant la VAT et en interceptant l'exception correspondante...

mais l'intercepetion sera aussi lancée à chaque recherche de variable, non ?

sinon, si tu cherches uniquement à intercepter le var-link dans le home, suffit de faire un tsr qui intercepte l'événement CM_KEY (=$710) avec comme message 2nd+-, non ?

ça me fait penser qu'il y a 2-3 trucs à corriger dessus

Les libs sont chargées au début du programme, et déchargées à la fin, donc entre deux appels, elles conservent les valeurs de leursvar globales (ou celles qui sont dans une section BSS, c'est le même principe).

si jamais ton programme peut en lancer un autre, fais gaffe car la lib peut être utilisé par un autre programme

oué, c'est tout à fait faisable, mais c'est très chiant à faire
et pour la plupart des libs, ça ne sert à rien
surtout si tu fais un shell, tu peux utiliser les RAM_CALL récents de preos, pour décharger les libs

euh dans ce cas tu peux reporter le problème dans le programme utilisateur, par exemple en obligeant à fournir une structure "fenêtre" à chaque appel de fonction de ta lib

./496: Techniquement il faudrait que je rajoute un flags dans la lib pour indiquer de separer les sections BSS en fonctions du programme courant. Mais j'ai la flemme et c'est dur. Et techniquement ta solution n'est pas du tout farfelue (ni dure a faire).

>Pas que j'ai de grandes ambitions sur l'utilisation de ma lib, mais je trouve ça plus 'propre' (en fait on m'a appris à programmer avec une barrière d'abstraction entre programmeur et utilisateur, c'est pour ça).
Tu peux donner l'ensemble des parametres dans un handle:
HANDLE WindowInit (...)
WindowDo (HANDLE h, ...)
WindowClear (HANDLE h)
C'est abstrait, et suffisament propre. Qui a dit que ca ressemblait aux systemes de TI

tu devrais peut-être regarder la structure Window et les fonctions qui l'utilisent

en ASM ? y a pas de souci par contre je ne sais pas si les nouveaux RAM_CALL sont définis. Au pire, tu peux toujours les appeler à la sauvage : jsr _RAM_CALL_014, par exemple

En ASM, il est clairement conseille d'utiliser le tios.h fournit avec Preos. Les headers ASM de tigcc sont obsoletes (et ceux meme pour le nostub !) ( (c) & TM )