Utilisation d'une lib kernel en archive - Page 1

ben passer par un registre ^^ (ou alors sauvegarder l'adresse du buffer à une adresse fixe genre vecteur inutilisé, mais c'est assez crade)

ah ok, c pas juste pour ton utilisation personnelle... ben non y a pas vraiment de solution, il faut que la fonction d'initialisation de la lib renvoie une adresse qui sera passée par la suite à toutes les autres fonctions de ta lib (si c'est pour être utilisé en C tu peux te débrouiller en passant par des wrappers qui s'occupent de stocker/passer cette adresse, mais en asm il faut faire la gestion soi-même)

ou alors, si la vitesse n'est pas importante, passer par une entrée avec un nom spécial dans la vat, ou chercher un handle avec une "signature magique"...

Mastergb avait fait ce qu'il appelait des "librairy read-only" qui permettait ce genre de chose, mais ce n'était que pour les libs perso bien sûr. Va jeter un coup d'oeil à datatolib v2 si ça t'intéresse.

PpHd, a quand une base de registre ?

Faut qu'il vois avec Flanker

Ben des que suffisament de monde la demande. Plus serieusement, la lib de Flanker fait tres bien l'affaire pour gerer une pseudo-base de registre.

sinon tu peux aussi stocker des trucs au sommet de la pile superviseur à la rigueur (un peu comme les sauvegardes de phoenix)
mais bon c'est un peu gore et surtout pas tout à fait garanti non plus

(quoi que, en rajoutant une espece de checksum, tu pourrais detecter si tes données sont corrompues ou pas)

T'as qu'à faire une lib réentrante et t'auras pas de problèmes......y compris si plusieurs programmes t'utilisent en même temps.
(j'ai horreur des fonctions pas réentrantes)

Oh que si. Ca permet d'appeler les fonctions de ta lib depuis une interruption, par exemple.
Ca permet à une autre lib d'utiliser la tienne sans risque de conflit.
De par sa construction, elle n'a pas à écrire dans son code (enfin attention à ne pas générer de relocations) donc peut être conservée en mémoire d'archive.

Oui, je vois pas trop ce que la réentrance vient faire là-dedans

Ben si, complètement, ça coïncide pas avec la définition qu'ils donnent sur Wikipédia ? (= segment de code réutilisable par plusieurs processus = pas de relogements autres que vers le code lui-même)

Mais, le problème est le même que jusqu'à ./11, non ?

ben, oui, à part que la réentrance exclut les hacks qui utilisent un espace global ^^ (et qu'en plus dans un certain nb de cas, c'est qd même une propriété intéressante à avoir)


EDIT : mais bien sûr, le fait qu'AMS (ou pedrom) ne soit pas réentrant ne garantit pas du tout la réentrance du programme (le moindre HeapAlloc() et tout est par terre), ce qui limite l'utilité d'exposer une interface potentiellement réentrante... à quand quelqu'un pour nous pondre un wrapper réentrant pour le TIOS ?

Pour PedroM, tu as les sources.

Extended> si la lib est réentrante, et qu'elle n'utilise pas de relogements au runtime, alors elle peut être exécutée depuis une zone mémoire en lecture seule, la réentrance excluant, comme l'a dit Pollux, toute donnée globale ou statique non constante.

Pollux> le problème c'est que dans un environnement non multithreadé, mettre un verrou risque de ne pas être simple à implémenter : si le verrou est déjà posé, que fait ton gestionnaire d'interruption ? (remarque tu me diras au moins il peut le savoir ce qui lui évite de planter tout).

D'un autre côté en environnement non multithreadé, on bénéficie quand même de la possibilité d'avoir plusieurs libs utilisant une autre lib dans le même programme, ce qui est quelque chose qui peut être pratique.

spectras
: Pollux> le problème c'est que dans un environnement non multithreadé, mettre un verrou risque de ne pas être simple à implémenter : si le verrou est déjà posé, que fait ton gestionnaire d'interruption ? (remarque tu me diras au moins il peut le savoir ce qui lui évite de planter tout).

C'est facile, à condition bien entendu que les deux processus soient gentils (l'interrompant et l'interrompu), l'interrompant laisse l'interrompu s'exécuter jusqu'à ce que le verrou soit relâché, et à ce moment-là il reprend la main et se fait plaisir... Evidemment, c'est une forme d'"environnement multithreadé" si on veut (puisqu'on repasse temporairement en non-superviseur en attendant que l'autre tâche se termine), mais faut pas déconner, c'est assez trivial... (et ça ne demande aucun effort de scheduling/toussa) Par contre ça rajoute une latence relativement imprédictible, mais ça on ne peut de toute façon pas y échapper...