Auteur
Yomgui
Yomgui
Forum » » Développement » » Les bibliothèques en mode 'baserel' et leurs problèmes...
Post� : 04-12-2009 14:38 
il faut que je fasse une page compléte juste pour expliquer les problèmes causés entre le baserel et Python.
Grosso merdo, Python exporte de façon directe plusieurs choses:
- Les fonctions de la lib elle-même (tous les Pyxx ou _Pyxxx).
- Les variables: tous les types et quelques variables et constantes.
Comme je l'explique dans ma FAQ, la compilations en baserel va permettre d'avoir ces variables définis par tâches et non pas globalement. Avec le script cv!!!include!!!s.pl dans le SDK de MOS on va aussi générer 2 choses:
- les inlines ppc
- les 'trampolines' pour la libpythonX.Y.a
Les deux permettent de sauver/restorer r13 dans la pile et forcer r13 avec le bloc de données sauvé quelque part dans la base (PythonBase) et ce avant l'appel effectif au code souhaité.
Ainsi le code est exécuté avec les bonnes données.
Evidement r13 est sauvé/restoré lors d'un switch de contexte du système.
Mais tout serait parfait dans le meilleurs des mondes si justement tout code utilisant la lib python n'appelerait QUE les fonctions de la lib.... sauf que le code python exporte des types!
Et un 'type' python c'est une structure contenant plein de fonctions... venant de partout (lib, module, extern) et donc pas de protection particulières vis-Ã-vis de r13 et pouvant être appelées de partout:
- si appel depuis la lib python: ok, r13 est déjà correct à ce moment là avec nos trampolines.
- si appel depuis un module .pym extern:
si ils sont compilés avec le module distutil que j'ai adapté pour mon port, alors pas de pb, car eux, bien qu'ils ne soient pas en baserel, j'utilise une option de gcc qui permet de ne pas générer d'instructions modifiant r13. Et là on retombe dans le cas de base.
Et là les deux cas critiques non protégés (r13 n'est pas forcé):
- la fonction exportée par le type est appelé par un code quelconque (comme le fait blender en quelques endroits, par exemple): évidement ce code est compilé avec ces propres options et manière, on ne peut donc rien garantir sur r13!
- les modules peuvent aussi exporter des fonctions comme des API (cf http://docs.python.org/3.1/extending/extending.html#providing-a-c- api-for-an-extension-module ) utilisable par d'autres modules (là ça va car module python = r13 protégé), mais aussi par un code quelconque!! Et là c'est comme le cas d'avant!
Pour résumer, pour qu'un code quelconque, utilisant Python, fonctionne il faut:
1) aucun appel direct aux fonctions exportées dans les structure des types.
2) ne pas utiliser les API exportées, sauf si on protége r13 soit même!
Compiler ton code en baserel ne changera pas grand chose: il protégera la valeur de r13 avant tout appel externe certe, mais il protége sa valeur... et pas celle devant être utilisée pour l'appel!
Il faut absolument respecter mes 2 points sinon rien...
Il existe par contre 1 excéption seulement à ces régles: si ces appels (dans 1) ou 2)) ce font dans une fonction utilisée comme
méthode d'un type: puisque cette méthode est supposée être correctement appelée, r13 est correcte à l'appel! Mais cela implique que cette méthode ne soit en aucun cas en baserel! Il faut pas commencer à mélanger les bases entre elles.
Voilà d'ailleurs pourquoi les modules .pym ne sont pas compilés en baserel!
Enfin tu as compris... c'est super simple et cela m'a juste value quelques années de recherche et dévelopement.
Pour info: j'ai en plus ici passé sous silence comment j'exporte les variables globales entre la lib et le code l'utilisant! Tout une histoire... mais je sent que tout le monde est un peu fatigué avec un gros mal de crâne
Cet article provient de Meta-MorphOS
https://www.meta-morphos.org/viewtopic.php?topic=334&forum=52