J'ai eu une idée... - Page 4

C'est parce que trap empile non seulement l'adresse de retour, mais aussi la valeur du SR avant le trap Du coup il faut le dépiler avant de faire un rts...

T'as aussi la possibilité de passer en mode superviseur manuellement hein (sans dépendre du trap 12)

ben non tu peux pas toucher au sr en mode utilisateur.
ça donnerait plus quelque chose dans ce goût là :

    lea    illegal_vec,a0
    lea    super(pc),a1
    lea    $600001,a2

    bclr.b #2,(a2)
    move.l (a0),d0
    move.l a1,(a0)
    illegal
super:
    lea    6(a7),a7
    move.l d0,(a0)
    bset.b #2,(a2)

oui c'est 1111...

./99> oui, en fait cette méthode présente l'avantage de fonctionner quel que soit l'os installé.
L'inconvénient évident, c'est qu'elle prend plus de place.

Mais j'ai tendance à faire comme ça presque automatiquement, parce que j'ai pas mal développé sur d'autres plateformes 68k.

En même temps j'ai même pas testé que ça marche, j'ai recodé ça de tête vite fait, j'ai même pas de quoi assembler sous la main.

Tu devrais éviter, ça empèche ton programme de fonctionner en même temps que d'autres. Par exemple un debuggeur embarqué, un multitasker, un hook sur le trap en question. Le résultat sera un crash aléatoire.

Je comprends bien. D'un autre côté, le multithread sur TI n'a jamais été une de mes priorités. Il y aurait déjà bien des choses à revoir dans le format des programmes et des libs pour que ce soit possible (ben oui, utilise la même lib chargée par PreOS avec deux programmes lancés simultanément...

J'ai déjà fait hein
Ca marche très bien, pourvu que les variables internes des bibliothèques partagées soient sauvegardées avec le contexte de chaque application l'utilisant.

Donc perso, je n'en fais absolument pas une priorité. Seul le côté "hack" me dérange, et je voudrais savoir si un changement de AMS à ce niveau est possible.

TI ne fournit aucune garantie autre que l'api officielle. Donc oui, ils peuvent changer à peu près tout le reste.

./109> Le code binaire doit être hardcodé, et je ne vois pas bien pour quelle raison ils le changeraient, donc c'est peu probable que ça change, mais c'est qd même vachement gore, sans parler des débuggeurs et compagnie... En plus évidemment ça ne marchera pas si, entre le moment où tu modifies le trap 12 et le moment où tu le restaures, il y a du code extérieur susceptible d'appeler le trap 12 ^^

./111> nope. Le multitasker reconnait un certain nombre de libs (de toutes façons il n'existe pas non plus des dizaines de libs) et sauvegarde leurs variables internes avec le contexte. Il n'y a pas une instance par programme.

./113> nan ça fait partie de la philosophie 68000 : le code automodifiant n'est pas "supporté" (== ça marche mais à tes risques et périls, et c'est pas compatible entre différents procos de la série 68k). Et comme tu n'as pas de bonne raison d'écrire à une adresse relative au pc à part pour du code automodifiant, ben il n'y avait pas de raison logique de fournir cette possibilité.

Ben genlib je pouvais pas la supporter, elle dégage les interruptions quand elle se charge, du coup le multitasking tu peux oublier.
Sinon, bah oui, le programme lui-même était un empilement de hacks divers et variés de toutes façons

Ben un multitasker c'est un programme "système", tout comme un debugger, un kernel, etc. C'est moins choquant, ils sont "là pour ça". ^^
Vu que le 68000 ne satisfait pas les prérequis à la virtualisation de Popek et Goldberg de toutes façons, il est impossible de faire du multitasking ou du debugging transparent. A partir de là, tout s'enchaîne

Ca avance. C'est le principal.