Posté le 04/03/2024 08:35
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 190 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 06/04/2024 21:12 | #
And when the world needed him most, he returned
Citer : Posté le 06/04/2024 21:15 | #
@Lephenixnoir: en 9 ans il y a eu des progrès sur la maitrise des processeurs SH je vois. Un des soucis qu'on arrivait pas à résoudre avec la version g85 c'était les crash aléatoires lorsque la table d'interruptions était changée pour supporter les nuances de gris. Cela a été résolu j'imagine ? Je serais très curieux de savoir comment car j'avais pas mal cherché comment remplacer correctement l'implémentation de cette fichue table.
Citer : Posté le 06/04/2024 21:18 | #
Aujourd'hui on fait ce qu'on veut avec les interruptions, oui. Mais peut-être pas en résolvant votre bug, parce que si je me souviens bien ça utilisait le même concept que l'auto-debugger de Kristaba où une seule interruption était redirigée. Comme sur SH il n'y a pas de table mais un seul point d'accès pour toutes les exceptions et interruptions (le registre vbr) ça donnait des complications parce que le code essayait de partager la responsabilité entre l'OS et le programme selon le type d'interruption. Alors qu'aujourd'hui on a plus ou moins des kernels free-standing qui gèrent toutes leurs interruptions eux-mêmes et ils sont stables tous seuls.
Citer : Posté le 06/04/2024 21:22 | #
On changeait effectivement l'adresse de la table des interruptions de manière à ce qu'à l'offset 0x400 il y ait le code de gestion des nuances de gris.
Mais on aurait souhaité avoir une vraie table.
Comme on ne savait pas vraiment ce que devait faire les fonctions de cette table c'était compliqué. On essayé de copier le contenu de l'ancienne table, et juste remplacer le contenu à 0X400, mais ça ne marchait pas.
Vous implémentez la table complète maintenant ?
Citer : Posté le 06/04/2024 21:29 | #
Ah mais oui je me rappelle plus du contexte maintenant.
En effet il n'y avait essentiellement aucune chance que votre approche marche de façon stable. C'est vraiment pas une table ; le gestionnaire d'interruptions (à vbr+0x600) est une fonction qui récupère le numéro de l'interruption dans un registre et ensuite fait ce qu'elle veut avec ; elle peut faire une série de if si ça lui chante, auquel cas on peut pas séparer une interruption du reste facilement.
Les numéros d'interruptions sont des multiples de 32 pour permettre de faire un saut du type PC+=num mais je ne sais pas si c'est implémenté comme ça dans l'OS, et ça reste un peu shaky. Faudrait aussi copier le code du gestionnaire d'exceptions (vbr+0x100) et TLB miss (vbr+0x400).
Et donc la version de Kristaba dont je parle (pour le debugger) était expérimentale à côté de ça. Ça me revient maintenant parce que justement quand j'ai commencé le travail sur mon propre moteur de gris (qui est devenu gint ensuite) il m'a suggéré de partir de là. Sa version exécutait le code dont il avait besoin sur l'interruption du debugger et pour les autres il resautait directement à la vbr de l'OS sans essayer de copier son code. C'était tordu parce que l'OS modifie la vbr si tu lui donnes les contrôle, mais ultimement il arrivait à s'en sortir.
Cependant son code ne marchait pas sur SH4 pour d'autres raisons mais que je pouvais pas comprendre à l'époque, et j'ai dérivé sur gint (à gérer toutes les interruptions moi-même) avant de tenter de perfectionner ce système.
On ne connaît pas la table complète ; voici ce qu'on connaît et implémente. Y'a jamais besoin d'implémenter tout de toute façon, y'a un mécanisme matériel pour désactiver les interruptions qu'on ne comprend pas / ne sait pas gérer.