90

oui pour la première question (on passe bien en superviseur avec un trap #12)
et il me semble que masquer le bit S du SR suffit à basculer en mode utilisateur smile
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

91

92

93

94

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

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

95

96

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

97

98

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)

99

100

101

oui c'est 1111...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

102

103

./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.

104

105

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.

106

107

108

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.

109

110

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 wink
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.

111

112

./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 ^^

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

113

114

./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é.

115

116

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 grin

117

118

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 wink

119

120

Ca avance. C'est le principal.