>PpHd:
>_nostub et librairies statiques: programmes petits en taille totale. Mais l'ensemble de ces programmes est tres redondant.
>Libraries dynamiques: Programme permettant d'economiser de la taille au total. il y une optimisation de l'ensemble des programmes plutot que chaque programme individuellement.
Ça part du principe que beaucoup de programmes se servent exactement des mêmes routines. Ce n'est pas toujours le cas. Souvent, des programmes différents ont besoin de routines légèrement différentes. Si ces fonctions sont réunies dans une librairie statique (ou dans plusieurs, chacune adaptée à une utilisation particulière, ça ne change rien), chaque programme prend ce dont il a besoin, et seulement ce dont il a besoin.
>>il faut toujours envoyer la totalité de la librairie dynamique même si on n'en utilise qu'une seule fonction
>Et ou est le probleme ?
>Dans l'ensemble des programmes de la calc. Il y en a bien plusieurs qui vont l'uitliser.
Ça dépend de la fonction. Par exemple, la fonction "sprite 16x*y avec 3 gris (noir + 2 gris) + blanc transparent avec halo blanc" (ou
genlib::big_sprite si tu préfères
) est adaptée à des programmes bien particuliers (
SMA et
Chrono en l'occurrence). Pour un autre programme, on pourrait préférer par exemple "sprite 32*48 avec 3 gris (noir, gris foncé, blanc) + transparent avec halo gris clair" (je sais que c'est plus long à calculer, mais peut-être le programme n'a-t-il pas besoin d'une telle vitesse - et le fait d'avoir fixé la taille permet d'autres optimisations). Une librairie statique pourrait théoriquement contenir toutes les combinaisons imaginables (il faut évidemment que quelqu'un les programme
). Une librairie dynamique ne peut pas dépasser 64 KO, et doit limiter le gaspillage de place, donc ne peut pas se permettre cela. Donc les programmes client sont contraints à des compromis.
Un exemple concret: si je ne me trompe,
genlib ne laisse le choix qu'entre blanc transparent et noir transparent. Imagine maintenant que quelqu'un veuille faire
Tux Racer sur TI-89. (Rappel: Tux est un manchot. Autre rappel: Les manchots sont noirs et blancs.) Je pense que tu peux t'imaginer le problème qui se pose s'il veut utiliser
genlib...
>>Et je suis certain à presque 100% que le C avec ExtGraph est au moins 10 fois plus rapide que le BASIC.)
>Je dirais 100 mais c'est mon opinion.
J'ai dit 10 pour avoir une marge de sécurité.
>liquid: a long terme on va dire, un petit programme aura tout interet a etre en nostub, mais un gros programme serait mieux adapte en kernel
Aucun programme ne serait mieux adapté en kernel.
Surtout, plus le programme est gros, moins il laisse la place d'en mettre d'autres qui se servent du kernel et des librairies dynamiques utilisées, et donc plus les avantages du partage de code dynamique deviennent imperceptibles.
[edit]Edité par Kevin Kofler le 21-12-2001 à 21:17:45[/edit]
) est adaptée à des programmes bien particuliers (SMA et Chrono en l'occurrence). Pour un autre programme, on pourrait préférer par exemple "sprite 32*48 avec 3 gris (noir, gris foncé, blanc) + transparent avec halo gris clair" (je sais que c'est plus long à calculer, mais peut-être le programme n'a-t-il pas besoin d'une telle vitesse - et le fait d'avoir fixé la taille permet d'autres optimisations). Une librairie statique pourrait théoriquement contenir toutes les combinaisons imaginables (il faut évidemment que quelqu'un les programme 
Relis bien ce que j'ai mis. Je n'ai que cité liquid pour lui répondre qu'aucun programme ne serait mieux adapté au kernel. 
