le mistub - Page 1

J'aimerai savoir ce que c'est exactement car je ne l'ai vu qu'a peine évoqué a quelque endroit de la doc(a moins que j'aie loupé le passage interessant).
Quels sont les avantages, les inconvéniants?
Comment on programme en mistub?

Le mistub a un avantage :

Il possede deux points d'entrees :
_main qui est le point d'entree s'il y a un kernel. Donc la relocation kernel aura eu lieu.
_begin qui est le point d'entree sans kernel (mode _nostub) : seule la reloc pure a eu lieu.

Ensuite tout est possible.

Je signale que ce n'est pas supporté par TIGCC et ne le sera probablement jamais. Je ne vois pas du tout l'utilité. Autant programmer en _nostub seul si on doit de toute façon supporter les deux modes.

Sauf que certain peuvent préférer utilise un kernel quand c possible

Quel intérêt??? De toute façon, si on doit supporter les 2, on ne peut utiliser aucune des spécificités du kernel, donc autant utiliser le _nostub seul.

La seule utilisation du mistub qui me vient à l'esprit est de faire un programme qui fonctionne quand il n'y a pas de kernel, mais plante ou réinitialise la calculatrice quand il y en a un, ou l'inverse.
1. Il est évident que nous ne comptons pas supporter un mode qui encourage ce genre de pratiques.
2. Il y a d'autres solutions pour faire ça. Pas besoin de la complexité du mistub juste pour permettre ce genre d'âneries.

J'avoue que je comprends difficilement l'intérêt du mistub.
Mais je ne sais pas non plus ce qu'est le "relogement kernel".

Importations de librairies de ramcalls de romcalls de section BSS.
Vous faites ce que vous voulez ensuoite

Mais je ne comprends pas l'intérêt alors.
Imaginons un prog qui utilise justement ces spécificités, il ne pourra pas fonctionner en _nostub...
Finalement ce sera un prog kernel comme les autres.

> Importations de librairies de ramcalls de romcalls de section BSS.
Même si on démarre en mode Nostub?

Il pourra ne pas fonctionner a 100% de ses capacites.

une des fonctionnalites que je vois pr le mistub, c'est pr un doors-explorer, par exemple...
on le fait fonctionner en nostub... et si un kernel est installe, on permet la compression/decompresse via ziplib...
(oue, je sais, il y a complib... mais on peut faire la meme chose avec d'otres libs, et j'avais pas envie de chercher plus lo9in)

PpHd> c'est le genre de choses qu'on peut faire, non ?

Oué

ok

squale92 a écrit :
une des fonctionnalites que je vois pr le mistub, c'est pr un doors-explorer, par exemple...
on le fait fonctionner en nostub... et si un kernel est installe, on permet la compression/decompresse via ziplib... (oue, je sais, il y a complib... mais on peut faire la meme chose avec d'otres libs, et j'avais pas envie de chercher plus lo9in)

Ben, dans ce cas on réécrit (ou porte) la librairie comme ça a été fait avec ziplib plutôt que de limiter artificiellement les fonctionnalités en l'absence d'un kernel.

Ben, dans ce cas on réécrit (ou porte) la librairie comme ça a été fait avec ziplib plutôt que de limiter artificiellement les fonctionnalités en l'absence d'un kernel.

perso, ca me gave d'avoir 36 fois la meme librairie sur ma machine...
surtout qd elle existe deja en dynamique !

Le Mistub permet juste d'avoir 2 point d'entré au niveau du programme, c'est a dire 2 fonctions pouvant etre lancé par l'OS cad en C :

void _main()
{

}

void _begin()
{

}

Sachant que si la calculatrice a un kernel c le kernel qui decide de lancer _begin et si celui ci est inexistant, c la TI qui "lance" _main, ayu niveau code a ajouter, je vois pas ou il y a un pbm car il est inexistant. Donc l'argument de kevin ne tiens pas.

Pas besoin de la complexité du mistub juste pour permettre ce genre d'âneries.

Je vois pas en quoi sa pose pbm sachant que c le kernel et pas le linker qui fait le boulot

Sauf qu'en C c'est pas encore possible

LE pbm viens juste que le linker ne connait pas le format du stub correspondant c'est tout non ?

Oué.

Non, il y a aussi que le C ne gère pas du tout le mélange de conventions kernel/_nostub. On peut certes utiliser des conventions _nostub partout, mais à ce moment-là, autant utiliser le _nostub plutôt que le "mistub"...

Tss c sur que le boulot doit etre vachement dur je sens qu'un fork de TIGCC va finir un jour par etre obligatoire, attendont le nouveau linker avec la 0.95 et je sens que sa risque d'arriver

Kevin Kofler a écrit :
Non, il y a aussi que le C ne gère pas du tout le mélange de conventions kernel/_nostub. On peut certes utiliser des conventions _nostub partout, mais à ce moment-là, autant utiliser le _nostub plutôt que le "mistub"...

Le C

Faudrait pas plutot dire TIGCCLib ? sa me parraitrait plus correct

1. Bonne chance pour comprendre le fonctionnement du nouveau linker. PpHd (qui a eu une copie de l'alpha actuelle parce qu'il essaye d'y implémenter les tables de relogements compressées) dit qu'il est très complexe.

2. Il ne suffit pas d'adapter le linker, il faudrait des modifications radicales à TIGCCLIB pour permettre le mélange kernel/_nostub dans un même programme de manière propre.

godzil a écrit :
Le C
Faudrait pas plutot dire TIGCCLib ? sa me parraitrait plus correct

Euh, oui, tu as raison.

Oué le nouveau linker est vraiment complexe. Pourquoi faire simple quand on peut faire tres complique ? (Bon, y'a des raisons pour que ca soit si complexe)

J'aimerait bien zieuter les sources qd meme, juste histoire de voir.. A quand des beta publiques ?

PpHd
a écrit : Oué le nouveau linker est vraiment complexe. Pourquoi faire simple quand on peut faire tres complique ? (Bon, y'a des raisons pour que ca soit si complexe)

La complexité est là pour:
* pouvoir remplacer le système de patches par quelque chose de plus propre.
* permettre pas mal de nouvelles fonctionnalités, surtout au niveau du code de démarrage, mais pas seulement (on vous réserve pas mal de surprises déjà, et j'en prépare d'autres qui sont top-secret vu que je n'aime pas promettre quelque chose dont je ne suis pas sûr que ce sera réalisé (je ne m'appelle pas Pollux )).

godzil
a écrit : J'aimerait bien zieuter les sources qd meme, juste histoire de voir.. A quand des beta publiques ?

Avec TIGCC 0.95 bêta 1. (Sauf si Sebastian veut sortir une alpha du linker seul avant, mais je ne pense pas, vu qu'une utilisation optimale du nouveau linker nécessite des adaptations au niveau de TIGCCLIB. Les fichiers objet existants continueront à marcher (sauf si tu utilises le switch expérimental -freg-relative-an, auquel cas il faudra recompiler), mais ne pourront pas jouir de la plupart des nouvelles fonctionnalités sans recompilation.)

En mistub, on peut choisir de se lancer comme on veut en mode kernel ou en mode nostub (en fonction des arguments et pas en fonction de la présence d'un kernel). J'ai fait un programme de ce type et j'ai dû faire des modifs à l'éditeur hexa après coup (pas très pratique comme méthode)

Flanker
: En mistub, on peut choisir de se lancer comme on veut en mode kernel ou en mode nostub