Kernel et Nostub: pourquoi en préférer un plutot que l'autre? - Page 1

Je lance un débat sur les différences entre Kernel et Nostub, leurs avantages, leurs inconvénient... En espérant que nous pourront tous profiter des connaissances qui vont défiler ici, car il n'y a rien de mieux qu'un bon vieux petit débat pour apprendre plein de nouveaux trucs qui font que la vie du programmeur ne sera plus jamais la meme.

PS: j'aimerai bien qu'il n'y ai pas que PpHd et Kevin Kofler qui interviennent, car je n'ai pas créer ce topic pour cela. Donc je vuos invite tous à contribuer à ce débat. Merci d'avance, et bienvenue pour un débat qui s'annonce à rebondissement!!
C'est partie...

TRES TRES TRES TRES TRES TRES MAUVAISE IDEE !
je sais pas qui a délocké le topic (peut être yAro) mais c'est une (très? ) mauvaise idée...
il y a déjà eu des tas de topics la dessus, qui ont mis le forum a feu et a sang ce n'est pas la peine de recommencer... si tu veux t'informer la dessus, vas visiter les anciens topics, tu trouvera des choses qui pourront peut etre t'intéresser...

Mes raisons principales pour lesquelles je préfère le _nostub:
- C'est le mode "natif" des TI-89/92+. Pourquoi émuler une autre API quand il y en a déjà une. Ce n'est interessant que quand il y a des systèmes qui utilisent cette API "nativement". Mais dans le cas des kernels TI-89/92+, il n'y a que Fargo qui est vaguement "compatible" avec leur API, et c'est tout. Et la plupart des programmes pour kernel TI-89/92+ ne tourneraient jamais sous Fargo de toute façon (pas assez de mémoire, utilisation de ROM_CALLs qui n'existent pas sous Fargo, ...).
- C'est le mode de programmation le plus moderne pour TI-89/92+. Le mode kernel émule un vieux mode de programmation: celui de Fargo, qui a plus de 5 ans. Entretemps, il y a déjà plus de 2 ans, l'API native de AMS, les ROM_CALLs, a été documentée en détail par Zeljko Juric et entretemps aussi par TI eux-mêmes. Pourquoi émuler une vieille API quand on en a une récente? Et on n'a pas besoin de kernel si on n'utilise que les ROM_CALLs.
- C'est plus facile à utiliser: l'utilisateur entre le nom du programme suivi de (), appuie sur [ENTER] et ça marche. Pas besoin d'installer quoi que ce soit.
- Ça économise de la RAM: un kernel doit toujours être installé en RAM. Si on n'a que des programmes _nostub, tout peut être archivé.
- On économise la place prise par le stub et le header des programmes pour kernel.
J'en ai probablement oubliées d'autres.

Et pour répondre à l'argument que les kernels permettent les librairies dynamiques: Déjà, les librairies dynamiques sont aussi possibles en _nostub. Ensuite, à moins de créer un programme >64 KO, les librairies dynamiques sont à éviter absolument car:
- Elles créent souvent des conflits de version, voire même de nom. Exemples: util de PlusShell 0.99 vs. util de PlusShell 1.00 - même entre versions différentes du même shell, il y a eu des librairies incompatibles dans les 2 sens -, flib de Fargo vs. FLib de FL, ...
- Toutes les routines de la librairie dynamique doivent être présentes sur la calculatrice, qu'elles soient utilisées ou non. Avec une librairie statique, seules les fonctions effectivement utilisées seront présentes sur la calculatrice.
- Une conséquence de ceci: la flexibilité d'une librairie dynamique est limitée par sa taille. Une librairie statique peut être aussi flexible que le programmeur veut, c'est-à-dire offrir autant de variantes de la même fonction que le programmeur veut, puisque les variantes non utilisées ne seront pas présentes sur la calculatrice de toute façon.
- Toutes les routines de la librairie dynamique seront copiées en RAM au lancement du programme, qu'elles soient utilisées ou non, d'où gaspillage de RAM.
- C'est plus facile à utiliser. L'utilisateur n'a pas à s'occuper de l'envoi des librairies à la calculatrice. Il ne saura même pas qu'une librairie est utilisée (sauf en lisant ce fait dans la documentation du programme). Ça évite tous les problèmes du genre "Missing lib: dl_lib", "Wrong version: dl_lib", ... et facilite donc énormément l'usage d'un programme.
- Enfin, il existe beaucoup de librairies dynamiques communément utilisées qui ne font que réimplémenter des fonctions de AMS. Par exemple filelib: ce n'est qu'un wrapper autour de certains ROM_CALLs pour émuler une ancienne API qui n'a aucun intérêt par rapport à l'utilisation directe des ROM_CALLs appropriés et qui nécessite des wrappers pour rien.
- D'autres librairies dynamiques (par exemple userlib ou graphlib) réécrivent des fonctions de AMS et y rajoutent d'autres fonctions qui ne sont pas dans AMS. Là, aussi, ce n'est pas pratique du tout parce que les fonctions qui ne servent à rien (parce qu'elles sont déjà dans AMS) se retrouvent sur la calculatrice en train d'occuper de la mémoire, et en train d'occuper de la RAM pendant l'exécution du programme. C'est également du gaspillage.
Là encore, j'ai probablement oublié d'autres arguments.

sBibi a écrit :
TRES TRES TRES TRES TRES TRES MAUVAISE IDEE !
je sais pas qui a délocké le topic (peut être yAro) mais c'est une (très? ) mauvaise idée...
il y a déjà eu des tas de topics la dessus, qui ont mis le forum a feu et a sang ce n'est pas la peine de recommencer... si tu veux t'informer la dessus, vas visiter les anciens topics, tu trouvera des choses qui pourront peut etre t'intéresser...

Personne ne t'oblige à lire ce topic. Comme ça au moins on ne polluera pas tous les autres topics avec ce débat.

bon, v dormir je pe pa mempêcher de commenter 2-3 trucs (dzolé kevin )

- C'est le mode "natif" des TI-89/92+. Pourquoi émuler une autre API quand il y en a déjà une.

bah si tu veux faire des programmes lents, utilise les routines d'ams
j'adore le traceur de lignes g mêm pa essayé les polygones remplis

- C'est le mode de programmation le plus moderne pour TI-89/92+. Le mode kernel émule un vieux mode de programmation: celui de Fargo, qui a plus de 5 ans. Entretemps, il y a déjà plus de 2 ans, l'API native de AMS, les ROM_CALLs, a été documentée en détail par Zeljko Juric et entretemps aussi par TI eux-mêmes. Pourquoi émuler une vieille API quand on en a une récente? Et on n'a pas besoin de kernel si on n'utilise que les ROM_CALLs.

le plus moderne? bah si c le "mode "natif" des TI-89/92+" c pas le plus moderne dsl tu te contredis
Pourquoi émuler une vieille API quand on en a une récente? heu la je suis pas sur de te suivre... les kernels récents comme PreOs émulent une vieille API? bien sur quand j'installe un kernel, ma 92+ ams 2.05 se transforme en 92 I
et comme tlm n'utilise pas forcément QUE les rom calls...

- C'est plus facile à utiliser: l'utilisateur entre le nom du programme suivi de (), appuie sur [ENTER] et ça marche. Pas besoin d'installer quoi que ce soit.

bah, argument bidon, avec un kernel, tu tapes preos() puis paf! [ENTER] c vachement plus compliké hein?

Ça économise de la RAM: un kernel doit toujours être installé en RAM. Si on n'a que des programmes _nostub, tout peut être archivé.

bah, ça encore, pbl de taille des kernels -> argument bidon, ct valable du temps d'unios... la maintenant vu la taille de PreOs

- On économise la place prise par le stub et le header des programmes pour kernel.

bof, pour la place que ça prend... quand on voit le code asm dégeulé par tigcc, on se dit que le code stub fé pas perdre grand chose (bon bien sur, dans le cas des progs _nostub asm, bah...la encore, c'est franchement pas ça qui rend le plus de place... sauf si c'est un petit prog d'1 Ko...

J'en ai probablement oubliées d'autres.

surement... cherche, que je te les démolisse aussi

Et pour répondre à l'argument que les kernels permettent les librairies dynamiques: Déjà, les librairies dynamiques sont aussi possibles en _nostub.

bah ué c un argument de moins en faveur du kernel, mais 0 arguments en plus en faveur du _nostub

Ensuite, à moins de créer un programme >64 KO, les librairies dynamiques sont à éviter absolument car: - Elles créent souvent des conflits de version, voire même de nom. Exemples: util de PlusShell 0.99 vs. util de PlusShell 1.00 - même entre versions différentes du même shell, il y a eu des librairies incompatibles dans les 2 sens -, flib de Fargo vs. FLib de FL, ...

numéro de version... hhm tiens ça me dit qquechose... aah ué c preos qui m'a dit lotre jour "shrinklib: new version needed"

- Toutes les routines de la librairie dynamique doivent être présentes sur la calculatrice, qu'elles soient utilisées ou non. Avec une librairie statique, seules les fonctions effectivement utilisées seront présentes sur la calculatrice.

bah je préfère avoir une seule lib pour plein de progs que plein de progs avec les mêmes morceaux de code dedans... c un point de vue heu c sur que si c'est pour: jsr userlib::idle_loop c pas vraiment indispensable de se servir de userlib enfin bon, ça dépend du programmeur... mais un prog de merde en _nostub le sera aussi en kernel, et vace versi...

- Toutes les routines de la librairie dynamique doivent être présentes sur la calculatrice, qu'elles soient utilisées ou non. Avec une librairie statique, seules les fonctions effectivement utilisées seront présentes sur la calculatrice.

justement! ac les libs dynamiques tu les as qu'une seule fois, même si il y en a de pas utilisées, ça compense largement le surcout de mem demandé par plein de progs _nostub avec les mêmes routines de libs statiques dedans...

- Une conséquence de ceci: la flexibilité d'une librairie dynamique est limitée par sa taille. Une librairie statique peut être aussi flexible que le programmeur veut, c'est-à-dire offrir autant de variantes de la même fonction que le programmeur veut, puisque les variantes non utilisées ne seront pas présentes sur la calculatrice de toute façon.

bah, dans ce cas, ce n'est plus la lib d'origine, et au pire, en transposant ça au kernel, le programmeur réécrit la routine en question... AU PIRE ça revient au même qu'en _nostub pt de vue bouffage de mem...

- Toutes les routines de la librairie dynamique seront copiées en RAM au lancement du programme, qu'elles soient utilisées ou non, d'où gaspillage de RAM.

merde y a CF qui tourne sur ma calc... ça bouffe de la ram ce truc?

- C'est plus facile à utiliser. L'utilisateur n'a pas à s'occuper de l'envoi des librairies à la calculatrice. Il ne saura même pas qu'une librairie est utilisée (sauf en lisant ce fait dans la documentation du programme). Ça évite tous les problèmes du genre "Missing lib: dl_lib", "Wrong version: dl_lib", ... et facilite donc énormément l'usage d'un programme.

Wrong version? mais tu te contredis avec ce que t'as dit au dessus concernant les "conflits de version"...
et facilite énormément l'utilisation d'un programme... hum c'est sur que pour les neu² c plus simple... bah t'envoie la lib sur ta calc une fois pour toutes en attendant la prochaine version, tu l'archive (si la calc le permet ) et voila... je vois pas ou c'est compliqué... c'est comme ton coup de taper le nom du kernel "suivi de ()" () qui est trop fatiguant lol

Enfin, il existe beaucoup de librairies dynamiques communément utilisées qui ne font que réimplémenter des fonctions de AMS. Par exemple filelib: ce n'est qu'un wrapper autour de certains ROM_CALLs pour émuler une ancienne API qui n'a aucun intérêt par rapport à l'utilisation directe des ROM_CALLs appropriés et qui nécessite des wrappers pour rien.

je ne me suis jamais servi de filelib... c'est juste plus simple a utiliser pour les débutants (je suppose sinon si c plus compliké que les ROM_CALLS filelib est vraiment mal foutue )

- D'autres librairies dynamiques (par exemple userlib ou graphlib) réécrivent des fonctions de AMS et y rajoutent d'autres fonctions qui ne sont pas dans AMS. Là, aussi, ce n'est pas pratique du tout parce que les fonctions qui ne servent à rien (parce qu'elles sont déjà dans AMS) se retrouvent sur la calculatrice en train d'occuper de la mémoire, et en train d'occuper de la RAM pendant l'exécution du programme. C'est également du gaspillage.

On en revient toujours au même... tu as l'air d'être marié à ams kevin... oui effectivement graphlib reprogramme des fct d'ams, mais ams est LENT, les fct de graphlib, même si elles ne sont pas fulgurantes de rapidité (on peut tjrs aller plus vite) sont quand même plus rapide (bcp ) que celles d'ams
la encore si c'est pour faire un pauvre prog qui affiche "bonjour" et deux lignes horizontales en dessous, c'est pas vraiment la peine d'utiliser graphlib, effectivement les romcalls suffiraient certainement

C'est également du gaspillage

oui, t'as raison, c'est une honte!!!! il faut virer ams!!! (heu, la il va me taper le kevin )

Là encore, j'ai probablement oublié d'autres arguments.

je te fais confiance, préviens moi quand t'en aura trouvés d'autres, que je les casse aussi

Personne ne t'oblige à lire ce topic. Comme ça au moins on ne polluera pas tous les autres topics avec ce débat.

je crois que le débat nostub/kernel a déja pollué le forum entier, et ce depuis un bon moment... (oui je c j'ai pas mi le underscore a nostub...)
boon, v dormir
(dsl pour le surcout de smiley )

Edit: j'avais oublié les citations lol

pour résumer en 1 phrase le discours de sBibi : KERNEL RULEZ !!!!

c'est ze diktator qui est passé par la qui l'a reouvert, je n'y peux rien, chacun son avis, je ne vais pas le refermer, mais on connait deja tous les tenats et aboutissants des avis de chacuns, ca ne peut que provoquer des tensions, voila pourquoi je l'avais fermé a l'orignie, mais soit, s'il a ete reouvert, je ne vais pas le refermer.

ct toi qui l qvqit ferme? c etait une tres bonne initiative freka
malheureusement, Kevin a fait son caprice, et le @ bleu la reouvert...

sBibi a écrit :
bah si tu veux faire des programmes lents, utilise les routines d'ams
j'adore le traceur de lignes g mêm pa essayé les polygones remplis

AMS est suffisamment rapide pour pratiquement toutes les utilisations. Pour les autres, il y a ExtGraph ou _X_Lib.

le plus moderne? bah si c le "mode "natif" des TI-89/92+" c pas le plus moderne dsl tu te contredis

C'est le plus moderne parce que l'autre est le mode utilisé sur les TI-92!

Pourquoi émuler une vieille API quand on en a une récente? heu la je suis pas sur de te suivre... les kernels récents comme PreOs émulent une vieille API? bien sur quand j'installe un kernel, ma 92+ ams 2.05 se transforme en 92 I

Ne fais pas semblant de ne pas avoir compris!

et comme tlm n'utilise pas forcément QUE les rom calls...

Si c'est seulement pour les librairies dynamiques que tu veux utiliser un kernel, j'ai déjà répondu plus bas. Ça n'apporte rien d'autre.

bah, argument bidon, avec un kernel, tu tapes preos() puis paf! [ENTER] c vachement plus compliké hein?

Si:
- Il faut lancer 2 programmes, pas un seul.
- Ce n'est pas logique de devoir "installer" un autre programme avant de pouvoir lancer le programme qu'on veut exécuter. Je trouve ce concept totalement illogique et compliqué.

bah, ça encore, pbl de taille des kernels -> argument bidon, ct valable du temps d'unios... la maintenant vu la taille de PreOs

5,5 KO. Ce n'est pas tellement plus petit que Universal OS, et il y a la taille des librairies dynamiques à rajouter.

numéro de version... hhm tiens ça me dit qquechose... aah ué c preos qui m'a dit lotre jour "shrinklib: new version needed"

Voilà déjà un exemple d'un conflit de version embêtant. Surtout qu'il est imaginaire. (La version en question marcherait très bien si PreOs ne râlait pas!)

bah je préfère avoir une seule lib pour plein de progs que plein de progs avec les mêmes morceaux de code dedans... c un point de vue

Même quand on recopie les fonctions dans chaque programme, ça prend toujours moins de place que celle utilisée par toutes les fonctions inutiles de style userlib::idle_loop.

heu c sur que si c'est pour: jsr userlib::idle_loop c pas vraiment indispensable de se servir de userlib

En effet.

enfin bon, ça dépend du programmeur... mais un prog de merde en _nostub le sera aussi en kernel, et vace versi...

Quel est le rapport avec les librairies dynamiques?

justement! ac les libs dynamiques tu les as qu'une seule fois, même si il y en a de pas utilisées, ça compense largement le surcout de mem demandé par plein de progs _nostub avec les mêmes routines de libs statiques dedans...

Non. Il y a beaucoup trop de fonctions inutiles pour que ça soit le cas.

bah, dans ce cas, ce n'est plus la lib d'origine, et au pire, en transposant ça au kernel, le programmeur réécrit la routine en question... AU PIRE ça revient au même qu'en _nostub pt de vue bouffage de mem...

Je ne parle pas de "bouffage de mem", mais d'utilité de la librairie.
Et puis le cas de la librairie dynamique donne plus de "bouffage de mem", parce qu'il y a des fonctions de la librairie dynamique qui traînent inutilisées parce qu'on les a réécrites (puisqu'elles étaient inadaptées).

merde y a CF qui tourne sur ma calc... ça bouffe de la ram ce truc?

Plein même!

Wrong version? mais tu te contredis avec ce que t'as dit au dessus concernant les "conflits de version"...

Pas du tout: un message "wrong version" est un conflit de version!

et facilite énormément l'utilisation d'un programme... hum c'est sur que pour les neu² c plus simple... bah t'envoie la lib sur ta calc une fois pour toutes en attendant la prochaine version, tu l'archive (si la calc le permet ) et voila... je vois pas ou c'est compliqué... c'est comme ton coup de taper le nom du kernel "suivi de ()" () qui est trop fatiguant lol

Un programme facile d'utilisation doit être conçu pour être utilisable par le pire des idiots! Sinon, ce n'est pas un programme facilement utilisable!
Et c'est lourd de devoir à chaque nouvelle version de PreOs:
- désarchiver toutes les librairies (que je dois d'abord chercher longtemps dans mes 109 variables dans _main - et encore, c'est sur ma TI-92+; sur ma TI-89, j'en ai 321 !)
- réenvoyer les nouvelles librairies
- archiver les nouvelles librairies (encore en les cherchant longtemps)

On en revient toujours au même... tu as l'air d'être marié à ams kevin... oui effectivement graphlib reprogramme des fct d'ams, mais ams est LENT, les fct de graphlib, même si elles ne sont pas fulgurantes de rapidité (on peut tjrs aller plus vite) sont quand même plus rapide (bcp ) que celles d'ams
la encore si c'est pour faire un pauvre prog qui affiche "bonjour" et deux lignes horizontales en dessous, c'est pas vraiment la peine d'utiliser graphlib, effectivement les romcalls suffiraient certainement

Si AMS ne suffit pas, on utilise ExtGraph ou _X_Lib, je ne vois pas où est le problème. Et dans la plupart des cas, AMS suffit largement!

je lqisse PpHd repondre

y'a un truc qui me fait rire :

Et dans la plupart des cas, AMS suffit largement!

là, je rigole !

Si David lorsqu'il a cree Fargo a decide d'implemnter les libraries dynamiques, ce n'est pas pour rien. Le code pour gerer les librairies dynamiques n'est pas facile et est assez complexe a deboguer. Pourquoi l'a-t-il donc fait ? Parce que tous les systemes d'exploitation modernes, windows 95, 98, nt, xp, Linux, solaris, beos, Freebsd, ... le font. Pourquoi des milliers de programmeurs ont decide de faire ainsi ? Suppposons un programme qui utilise une librairie statique. Si un bug survient dans une des routines de la librairie statique a cause d'une bogue pur, ou d'une mise a jour du materiel. Il est necessaire de recompiler tout le programme pour corriger le bogue. Si plusieurs programmes utilisent la librairie statique, il est necessaire que le programmeur se maintienne au courant des mises a jour a de la lib statique, et qu'a chaque mise
a jour, ils remettent a jour son programme. S'il a beaucoup de programmes, ca peut devenir infernal et on passe des heures a faire les mises a jour. Si le programmeur ne maintient plus le programme, on n'a aucune facon de pouvoir corriger le bogue de la librarie statique. En lib dynamique, on peut corriger cela.
On met a jour la librarie dynamique, et on n'a pas besoin de remettre a jour les programmes par ailleurs. C'est une enorme avantage. Par ailleurs, l'utilisateur peut mettre a jour de lui meme la librairie. il a plus de controle, contrairement a une lib statique ou le programmeur est omnipotent (si ca plante, ca ne peut etre que de sa faute. Alors qu'avec une lib dynamique, ca peut etre la faute de l'utilisateur). Bref en
tant que programmeur /utilisateur j'aime garder un peu de controle.

AMS est le systeme d'exploitation des ti-92 +/ ti89. C'est un systeme de calcul formel, possedant de nombreuses fonctions. Mais il n'est pas complet. Il lui manque des fonctions de niveaux de gris, de compression. par aileurs, il n'est pas tres rapide (surtout sur les fonctions graphiques), parfois obscur (ROM_calls longtemps non documentees, et encore aujourd'hui certaines le restent), impose des limitations aux programmes (Pas de ER_throw, pas de retour d'expression, limitation en taille du programme, limitation taille des archives). Bref il n'est pas parfait.

Le format des programmes asm sur TI est tres simple : CODE + RELOC_TABLE + TAG_DE_FIN. Or les programmes modernes utilisent en plus des sections codes, les sections BSS, les sections DATA (En ro), les sections DATA (En rw), les importations de librairies, etc.
Le but des kernels inventes par Xavier Vassor et Rusty Wagner, est donc d'offir au programmeur un environnement de programmation plus moderne, et plus a jour que cette malheureuse section de code. Leur format n'est pas parfait.
Le passage de PlusShell v0.9 a PlusShell v1.00 a ete suivi par un changement de format, ce qui a rendu les programmes compiles avec plusshell v0.9 incompatibles avec la nouvelle version (un utilitaire de convertion existait).
Le passage a la rom 2.0x a engendre aussi des problemes car des constantes ont change et ne sont plus constantes selon les versions d'ams. Oui le format kernel etait pas parfait au debut, mais il a su evoluer tout en gardant le meme format. L'arrivee de Preos a permis de rajouter des possibilites qui manquaient a savoir l'importation de
libraries a la volee, la possibilite qu'une librairie soit en read_only, et les numeros de versions de librairies qui assurent la penerite de l'importation a la librairie.

Le mode nostub est un mode simple : une section, pas d'importations.
Le mode kernel est une surcouche au mode nostub : section code, bss, importations de libraries, ...
Le but est donc de fournir plus de fonctionnalites aux programmeurs.
Cela un coup : on doit installer un kernel avant d'utiliser le programme. Soyons honnete, cela ne prend que peu de temps. Il prend de la RAM pour s'installer en TSR. Soit. Mais un programme kernel tournant sous Preos donnera plus de RAM libre qu'un programme nostub compile avec SAVE_SCREEN. Le kernel a permis d'ameliorer cette fonctionnalite sans recompiler les programmes.Par ailleurs, du fait de l'architecture du kernel, on peut supposer qu'il permettra une meilleure gestion de la memoire a l'aide de librairies dynamiques (Rien n'empeche que la libraire ne soit pas totalement charge en memoire et que si lorsqu'on appelle une fonction d'une lib cela la decompresse temporairement avant de l'executer. Mais ce n'est pas encore implemente. Une autre
possibilite est de faire des programmes auto-extractibles en une seule couche (Sans rajouter de launcher).
Mais ce n'est pas encore implemente.


Certes, en mode nostub, on economise la place prise par le stub, puisqu'il n'y est pas. Mais apres, il faut rajouter les couches SAVE_SCREEN / CALC_DETECT / AMS_CHECK (que le kernel fait tout seul) et si on utilise les modules externes nostub (Je n'appelle pas ca libraries desole), le code de chargement. En outre le format de relocation est plus gros. Tous ces arguments font que le stub du programme kernel n'est pas si gros, et
qu'un programme recompile en mode kernel sera souvent plus petit (Sauf pour les petits programmes).

Ensuite, comme je l'ai mentionne plus haut, le mode nostub ne gere pas les libraries dynamiques, mais plutot des modules externes nostub, qui permettent de depasser la limite des 64K. Or l'appel de ces fonctions est relativement lourd et lent. Par ailleurs il ne permet pas d'en charger plus d'un a la fois sauf en utilisant une bidouille (relativement simple). Enfin, le seul programme nostub qui aurait gagne a exploiter les modules externes nostub, a savoir le FAT engine de la Tict, n'utilisera pas les modules externes, car la recompilation d'un des programmes ayant besoin du FAT engine (corridor92) avec le mode module externe, fait depasser corridor92 la taille des 64 K. or comme on ne peut pas charger plus d'un module a la fois, c'est fini.

Les conflits de version des libs kernels appartiennent a la prehistoire, comme aurait pu dire Kevin. Il n'en a plus, surtout depuis l'arrivee des numeros de versions.
Toutes les routines d'une lib dynamique doivent etre presentes dans la calc, certes mais ou est le probleme ?
Un probleme tres embetant des librairies statiques, outre ceux deja explicites, est que :
je vais prendre l'exemple de genlib en mode statique, si elle avait existe. 95% des fonctions sont liees entre elles (lors de l'initialisation, genlib reinit pas mal de choses en appellant les fonctions necessaires, et certaines fonctions de bases telles gl_set-dscreen_function font du self modifying code sur 80 % des fonctions). ceci rend un bloc static genlib inflexible, a disons 15 K.
Sur ma calc, je possede Cf, SMA, pokered et Total. 4 jeux necessitant genlib.
Si c'etait une lib statique, chacun aurait du avoir sa version de la lib statique, et donc cela aurait fait 15K * 4 = 60 K de libraire genlib sur la calc. Comme c'est une lib kernel, elle ne prend que 18 k sur la calc, soit un gain de pres de 42 K, en evitant la redondance du code.
Par ailleurs, je n'aurais a mettre a jour qu'un seul fichier pour corriger des bogues, et pas 4. Ce qui economisera un peu la memoire archive.

Certes, cela impose qu'une lib dynamique est limite en taille (plus de 20 K ?) : il ne faut pas que ca soit trop gros. Donc avec une lib statique on peut multiplier les fonctions avec plein de methodes d'appels differents. Ceci est bien pour la performance. On peut s'adapter au cas par cas. Mais cela un effet pervers.
Un programme peut grossir tres rapidement parce que le programmeur va utiliser plein de fonctions differentes. Il va utiliser trop de fonctions differentes, et chacune d'entre elles va devoir avoir son code dans le programme final. Bref, la multiplication des fonctions est bien, mais ajoute le risque d'augmenter de maniere exedentaire le code final, sans reelle necessite (On aurait pu se debrouiller avec d' autres fonctions et donc utiliser seulement un sous-ensemble de celles-ci, pour obtenir un code plus petit ).

Un autre inconvenient des libs dynamiques est qu'il faut la charger completement. On ne peut pas (encore ? c'est en projet) charger une sous-partie de celle-ci. Mais tout d'abord, je n'ai jamais entendu parler de problemes concrets. Souvent entendu en theorie, jamais demontre en pratique. Ensuite, preos v0.58 supportera
le package de libraries compressees : on pourra faire plein de sous libs dynamiques, que l'on compressera ensemble et reliera dans un seul fichier.

Certes je suis obblige d'admettre que certaines libs dynamiques sont desuees, tels que filelib/util/gray4lib. Elles ont existes pour des raisons historiques, lorsqu'on ne connaissait pas les ROM_CALLS. Il n' est pas necessaire de les utiliser maintenant. On peut s'en passer.

En ce qui concerne graphlib, soit elle offre des variantes bien plus rapides qu'ams comme fonction (line / sprite), soit elle offre des fonctions qui n'existent pas (gray). le cas de userlib est quand meme plus discutable, il est vrai.


Pour toutes ces raisons, et pour surement d'áutres je prefere rajouter un format supplementaire au format nostub.

Kevin Kofler a écrit :
AMS est suffisamment rapide pour pratiquement toutes les utilisations. Pour les autres, il y a ExtGraph ou _X_Lib.

Si Extgraph / xlib etaitent des libraries dynamiques ont economiserait pas mal de place.

C'est le plus moderne parce que l'autre est le mode utilisé sur les TI-92!

Ah ! Et alors ? tu connais le mot regression ? Le format Fargo etait vraiment bien foutu, et c'est encore mon prefere.

Si c'est seulement pour les librairies dynamiques que tu veux utiliser un kernel, j'ai déjà répondu plus bas. Ça n'apporte rien d'autre.

Et pour economiser de la place.

Si:
- Il faut lancer 2 programmes, pas un seul.
- Ce n'est pas logique de devoir "installer" un autre programme avant de pouvoir lancer le programme qu'on veut exécuter. Je trouve ce concept totalement illogique et compliqué.

Si tu veux je peux faire, preos("monprog").
Ca sera pareil et ca marchera tres bien.

5,5 KO. Ce n'est pas tellement plus petit que Universal OS, et il y a la taille des librairies dynamiques à rajouter.

Tu choisis la version que tu souhaites de preos. Perso, moi c'est 2.5 K installe en TSR.

Voilà déjà un exemple d'un conflit de version embêtant. Surtout qu'il est imaginaire. (La version en question marcherait très bien si PreOs ne râlait pas!)

Il fallait mettre a jour et faire abstraction du passe, pour repartir sur des bases propres.

Même quand on recopie les fonctions dans chaque programme, ça prend toujours moins de place que celle utilisée par toutes les fonctions inutiles de style userlib::idle_loop.

Je suis d'accord pour userlib::idle_loop. Pas pour les autres.

Non. Il y a beaucoup trop de fonctions inutiles pour que ça soit le cas.

Exemples ?

Je ne parle pas de "bouffage de mem", mais d'utilité de la librairie.
Et puis le cas de la librairie dynamique donne plus de "bouffage de mem", parce qu'il y a des fonctions de la librairie dynamique qui traînent inutilisées parce qu'on les a réécrites (puisqu'elles étaient inadaptées).

La compatibilite des vieux programmes est elle un peche ?

Pas du tout: un message "wrong version" est un conflit de version!

On peut le voir comme ca.
Moi il me semble qu'un conflit de version survient lorsque deux programmes necessitent deux versions differentes et incompatibles entre elles de la meme librairie.
Pas une simple mise a jour.

Un programme facile d'utilisation doit être conçu pour être utilisable par le pire des idiots! Sinon, ce n'est pas un programme facilement utilisable!

Le pire des idiots ne sera pas lancer le programme alors...
Et il aura autant de ttstart que de programme. A le gain, il est vraiment grand

Et c'est lourd de devoir à chaque nouvelle version de PreOs:
- désarchiver toutes les librairies (que je dois d'abord chercher longtemps dans mes 109 variables dans _main - et encore, c'est sur ma TI-92+; sur ma TI-89, j'en ai 321 !)
- réenvoyer les nouvelles librairies
- archiver les nouvelles librairies (encore en les cherchant longtemps)

Que veux-tu ? Je te conseille de prendre une femme de menage alors.

Si AMS ne suffit pas, on utilise ExtGraph ou _X_Lib, je ne vois pas où est le problème. Et dans la plupart des cas, AMS suffit largement!

Et ziplib::compress ? Dommage que tigcc.a / extgrpah.a / xlib.a ne soient pas des libs dynamiques. On gagnerait beaucoup de place.

bravo, t as retape tout ca apres avoir plante... #clapclap#
bon, je suis 100% dacord avec PpHd

Je suis d'accord avec PpHd

sinon, oué le gain de place serait assez interessant ... DLL_ rulez ?

Sur ma calc, je possede Cf, SMA, pokered et Total. 4 jeux necessitant genlib

arrete, c'est impossible de caser ces jeux avec tous les niveaux de sma sur une TI

ben avec tous les lvls non .. mais c vrai que si tous ces jeux avaient été en nostub .. ben pour la place prise, ca aurait été horrible ...

Je suis également 100% d'accord avec PpHd...

De plus j'ajouterais que le probleme kernel/nostub n'embete que les pro-nostub parce qu'ils n'ont pas de kernel et donc ne peuvent pas utiliser tous les programmes. Ceux qui ont un kernel n'ont pas ce probleme. J'ai fait le loader nostub pour genlib parce que ceux qui ne veulent pas de kernel ne pouvaient pas s'en servir.

liquid
a écrit : arrete, c'est impossible de caser ces jeux avec tous les niveaux de sma sur une TI

Un niveau seulement de SMA, c'est vrai.

et bien vire ce jeu, pour un niveau, c pas la peine

ça faisait longtemps tiens...

oué, je confirme, PpHd n'a que "chaos1" sur sa calc pour SMA !

bah moi je suis partagé en fait, c vrai que les libs dynamiques ont l'avantages de stocker toutes les fonctions dans un fichiers (ex : genlib), et ensuite les codeurs peuvent s'en servir, sans avoir à recopier le code de chaque fonction dans le pro (ce qui se passe lors de la compil avec TIGCC par ex).
Alors qu'avec des libs statics (Xlib), si on a 3 gros jeux sur notre calc utilisant une lib, bah ça fait 3 fonctions recopiées dans les progs.

Mais bon, Kevin a aussi cités les inconvenients des libs dynamiques, et c'est vrai que pour certain c'est chiant (copie en RAM des fonctions ect).

Donc voili voilà ...

de toute façon, après c'est à l'utilisateur de décider, et de prendre une lib performante (graphique par ex). Mais là encore on a plusieurs choix (en C, Xlib et Genlib ).

et si Xlib etait en flash???

PpHd
a écrit : Si David lorsqu'il a cree Fargo a decide d'implemnter les libraries dynamiques, ce n'est pas pour rien. Le code pour gerer les librairies dynamiques n'est pas facile et est assez complexe a deboguer. Pourquoi l'a-t-il donc fait ?

Parce qu'il n'est pas parfait! Personne n'est parfait!
Les utilisateurs n'ont jamais aimé les librairies dynamiques: par exemple, sur TI-85, les auteurs du shell Usgard ont vite supprimé le support pour les librairies dynamiques à la demande des utilisateurs. Ils l'ont remplacé par un paquet de routines qui si j'ai bien compris la documentation marche à peu près comme une librairie statique.

Parce que tous les systemes d'exploitation modernes, windows 95, 98, nt, xp, Linux, solaris, beos, Freebsd, ... le font.

1. Ces systèmes ne sont pas parfaits non plus! (Loin de là!) Il y a toujours plein de problèmes à cause des DLLs manquantes, trop vieilles, dans le mauvais répertoire, etc... Et sous Linux par exemple, il y a le gros problème du "dependency hell": souvent, quand on veut installer un programme, on se retrouve à d'abord devoir télécharger et installer une trentaine de paquets (voire même plus - ce sont plus de 60 pour GnuCash par exemple) pour pouvoir utiliser un seul programme. C'est tout sauf pratique!
2. Ces systèmes ne sont pas faits pour une calculatrice! Et ils ne marcheront jamais sur une calculatrice: on ne peut pas faire tenir 30 librairies dynamiques différentes par programme sur une calculatrice.

Pourquoi des milliers de programmeurs ont decide de faire ainsi ?

Parce qu'ils sont trop paresseux pour recompiler leurs programmes?

Suppposons un programme qui utilise une librairie statique. Si un bug survient dans une des routines de la librairie statique a cause d'une bogue pur, ou d'une mise a jour du materiel. Il est necessaire de recompiler tout le programme pour corriger le bogue. Si plusieurs programmes utilisent la librairie statique, il est necessaire que le programmeur se maintienne au courant des mises a jour a de la lib statique, et qu'a chaque mise a jour, ils remettent a jour son programme.

Ça prend 2 minutes.

S'il a beaucoup de programmes, ca peut devenir infernal et on passe des heures a faire les mises a jour.

Tu exagères. J'ai 3 TSRs utilisant h220xTSR.a et ce n'est pas si long que ça de les mettre à jour à chaque mise à jour de h220xTSR.

Si le programmeur ne maintient plus le programme, on n'a aucune facon de pouvoir corriger le bogue de la librarie statique.

On la patche. Si l'auteur de la librairie statique est encore actif, il n'aura pas trop de mal à patcher sa librairie.

En lib dynamique, on peut corriger cela.

Sauf quand l'auteur de la librairie dynamique a disparu sans laisser ses sources. (Exemple: ziplib - il y a plein de bogues là-dedans et on ne peut pas les corriger parce que les dernières sources publiées sont très vieilles.)

On met a jour la librarie dynamique, et on n'a pas besoin de remettre a jour les programmes par ailleurs. C'est une enorme avantage. Par ailleurs, l'utilisateur peut mettre a jour de lui meme la librairie. il a plus de controle, contrairement a une lib statique ou le programmeur est omnipotent (si ca plante, ca ne peut etre que de sa faute. Alors qu'avec une lib dynamique, ca peut etre la faute de l'utilisateur).

Et tu trouves ça bien? L'utilisateur n'a pas à s'occuper de décisions internes au programme telles que le choix de la version de la librairie. Et d'ailleurs avec le système actuel il se retrouve souvent avec une ancienne version. Et tes numéros de version n'apportent pas grand chose: au lieu d'avoir un plantage, il aura un "wrong version", ça ne lui apportera pas beaucoup.

Bref en tant que programmeur /utilisateur j'aime garder un peu de controle.

Mais tous les utilisateurs ne sont pas des programmeurs experts comme toi.

AMS est le systeme d'exploitation des ti-92 +/ ti89. C'est un systeme de calcul formel, possedant de nombreuses fonctions. Mais il n'est pas complet. Il lui manque des fonctions de niveaux de gris, de compression. par aileurs, il n'est pas tres rapide (surtout sur les fonctions graphiques),

Il est suffisamment rapide pour la plupart des utilisations.

parfois obscur (ROM_calls longtemps non documentees, et encore aujourd'hui certaines le restent),

Tu peux changer ça si ça te gène!

impose des limitations aux programmes (Pas de ER_throw,

http://tigcc.ticalc.org/doc/htretval.html#reterr

pas de retour d'expression,

http://tigcc.ticalc.org/doc/htretval.html#retval (Tiens, ça me fait penser qu'il faut que je rajoute IPR, KerNO et PreOs comme solutions pour utiliser la valeur retournée dans une expression.)

limitation en taille du programme,

Il y a ExePack pour ça.

limitation taille des archives).

Il y a MaxMem pour ça.

Bref il n'est pas parfait.

Mais on n'a pas besoin de kernel pour éviter ses limites.

Le format des programmes asm sur TI est tres simple : CODE + RELOC_TABLE + TAG_DE_FIN.

Ce qui est plus pratique pour tout le monde:
- C'est plus facile à comprendre pour le programmeur.
- C'est plus facile à générer pour le linker.

Or les programmes modernes utilisent en plus des sections codes, les sections BSS, les sections DATA (En ro), les sections DATA (En rw), les importations de librairies, etc.

Tout ceci complique de manière non nécessaire.
- BSS -> inutile: soit on met tout dans le segment de code, soit on l'alloue soi-mêmes, il y a tout un paquet de fonctions pour ça. Et c'est plus flexible (plusieurs blocs, possibilité de dépasser 64 KO, ...), plus rapide et prend moins de place (accès par x(an) au lieu de abs.l avec relogement).
- TEXT (code) / DATA ro / DATA rw: Pourquoi cette distinction pour un programme qui est entièrement dans la RAM dans un système sans MMU? Ça n'a aucun intérêt: on peut écrire partout de toute façon. (Et tu t'en sers bien dans genlib - c'est bourré de code auto-modifiant!)
- importations de librairies dynamiques: Pas besoin de faire ça dans le format des relogements. Tu t'es rendu compte toi même que le chargement dynamique est plus flexible vu que tu l'as rajouté dans PreOs.

Le but des kernels inventes par Xavier Vassor et Rusty Wagner, est donc d'offir au programmeur un environnement de programmation plus moderne, et plus a jour que cette malheureuse section de code.

Cette "malheureuse section de code" fonctionne très bien. La seule raison pour laquelle ils ont émulé un autre environnement de programmation est que c'était ce auquel ils étaient habitués par Fargo et qu'ils ne voulaient pas s'habituer à un environnement différent.

Leur format n'est pas parfait.

En effet.

Le passage de PlusShell v0.9 a PlusShell v1.00 a ete suivi par un changement de format, ce qui a rendu les programmes compiles avec plusshell v0.9 incompatibles avec la nouvelle version (un utilitaire de convertion existait).

Mais il fallait changer les noms des librairies! C'est une grave erreur que de donner le même nom de fichier à 2 librairies dynamiques binairement incompatibles!

Le passage a la rom 2.0x a engendre aussi des problemes car des constantes ont change et ne sont plus constantes selon les versions d'ams. Oui le format kernel etait pas parfait au debut, mais il a su evoluer tout en gardant le meme format. L'arrivee de Preos ...

Ça sent la publicité!

... a permis de rajouter des possibilites qui manquaient a savoir l'importation de libraries a la volee,

Voilà. Mais pourquoi alors disais-tu juste avant que c'était une bonne idée de mettre une table d'importation de librairies dynamiques dans le format des relogements?

la possibilite qu'une librairie soit en read_only,

Aucun intérêt par rapport à un simple fichier de données de type personnalisé.

et les numeros de versions de librairies qui assurent la penerite de l'importation a la librairie.

Ces numéros risquent de créer des incompatibilités inutiles parce que les programmes dépendront souvent de versions plus récentes de celles vraiment nécessaires. Et ça n'apporte pas grand chose d'autre (vu que la vérification du nombre des fonctions y était déjà). Sauf si c'est pour créer des librairies binairement incompatibles, mais là la vérification dans un sens seulement n'aidera pas.

Le mode nostub est un mode simple : une section, pas d'importations.
Le mode kernel est une surcouche au mode nostub : section code, bss, importations de libraries, ... Le but est donc de fournir plus de fonctionnalites aux programmeurs.

Ce sont des "fonctionnalités" inutiles qui ne font que compliquer la tâche:
- au programmeur
- au linkeur et
- au système runtime (auquel il faut rajouter un kernel parce que le format est trop compliqué pour AMS)

Cela un coup : on doit installer un kernel avant d'utiliser le programme. Soyons honnete, cela ne prend que peu de temps. Il prend de la RAM pour s'installer en TSR. Soit. Mais un programme kernel tournant sous Preos donnera plus de RAM libre qu'un programme nostub compile avec SAVE_SCREEN.

Avec h220xTSR, ça prend certainement plus de 3840 octets. Et SAVE_SCREEN utilise la pile, pas le heap, pour sauvegarder l'écran.

Le kernel a permis d'ameliorer cette fonctionnalite sans recompiler les programmes.

Je suis toujours contre ce système de redessinement parce que c'est plus compliqué qu'une simple sauvegarde sur la pile.

Par ailleurs, du fait de l'architecture du kernel, on peut supposer qu'il permettra une meilleure gestion de la memoire a l'aide de librairies dynamiques (Rien n'empeche que la libraire ne soit pas totalement charge en memoire et que si lorsqu'on appelle une fonction d'une lib cela la decompresse temporairement avant de l'executer.

Si: l'interdépendance entre les fonctions! Et comment le kernel peut-il savoir qu'une fonction ne réfère pas à une autre par un adressage PC-relatif? Par un flag peut-être, mais c'est toujours compliqué à calculer pour le kernel sauf si tu imposes des fonctions mises dans l'ordre, et il y a un grand risque d'erreur (que ce flag soit mis alors qu'il ne devrait pas l'être).

Mais ce n'est pas encore implemente.

Je ne pense pas que ça soit implémentable.

Une autre possibilite est de faire des programmes auto-extractibles en une seule couche (Sans rajouter de launcher). Mais ce n'est pas encore implemente.

On peut faire ça nous aussi si le programme compressé fait moins de 22,5 KO environ. Mais on ne le fait pas parce que ça ferait recopier le programme compressé en RAM 2 fois: une fois compressé et une fois décompressé. Je ne pense pas que tu pourras faire mieux en mode kernel.

Certes, en mode nostub, on economise la place prise par le stub, puisqu'il n'y est pas. Mais apres, il faut rajouter les couches SAVE_SCREEN / CALC_DETECT / AMS_CHECK (que le kernel fait tout seul)

Seulement si c'est nécessaire pour le programme. Il y a des programmes qui n'ont pas besoin de sauvegarder l'écran. Il y a des programmes qui sont compatibles avec tous les AMS (y compris AMS 1.00 pour TI-92+). Etc...

et si on utilise les modules externes nostub (Je n'appelle pas ca libraries desole), le code de chargement.

Il est toujours moins lourd que le kernel.
Et n'oublie pas la table d'importation et relogement des librairies dynamiques en mode kernel. Elle peut facilement prendre des dimensions non-négligeables.

En outre le format de relocation est plus gros.

Mais il y a une raison: ça permet d'interrompre le programme de manière abrupte (par un ER_throw par exemple) sans le corrompre.

Tous ces arguments font que le stub du programme kernel n'est pas si gros, et qu'un programme recompile en mode kernel sera souvent plus petit (Sauf pour les petits programmes).

Tu te rappelles l'essai que j'ai fait avec AutoClBr?
J'ai recompilé en mode kernel avec un header qui expandait les ROM_CALL en jsr doorsos::, et c'était plus gros que la version _nostub.
(D'ailleurs, ne me demandez pas la version kernel, je ne la distribuerai pas, vu qu'elle n'a aucun intérêt - elle est plus grosse - et qu'elle ne marcherait qu'avec Universal OS à cause de la libération automatique des handles des autres kernels.)

Ensuite, comme je l'ai mentionne plus haut, le mode nostub ne gere pas les libraries dynamiques, mais plutot des modules externes nostub, qui permettent de depasser la limite des 64K.

Ce sont quand-même des DLLs, même si nous ne voulons pas que tu les utilises de la manière de laquelle tu aimes utiliser les DLLs.

Or l'appel de ces fonctions est relativement lourd et lent. Par ailleurs il ne permet pas d'en charger plus d'un a la fois sauf en utilisant une bidouille (relativement simple).

Ça va peut-être changer à la demande de Thomas Nussbaumer.

Enfin, le seul programme nostub qui aurait gagne a exploiter les modules externes nostub, a savoir le FAT engine de la Tict, n'utilisera pas les modules externes, car la recompilation d'un des programmes ayant besoin du FAT engine (corridor92) avec le mode module externe, fait depasser corridor92 la taille des 64 K. or comme on ne peut pas charger plus d'un module a la fois, c'est fini.

De toute façon, FAT Engine utilise déjà son propre système de chargement de DLLs qui marche très bien (et duquel le système de Zeljko s'est inspiré). Il n'y a donc aucune raison de le changer à tout prix.

Les conflits de version des libs kernels appartiennent a la prehistoire, comme aurait pu dire Kevin. Il n'en a plus, surtout depuis l'arrivee des numeros de versions.

Les numéros de version ne changent absolument rien au problème. Ce n'est qu'illusoire comme solution. Tout ce que ça apporte, c'est encore plus d'erreurs "wrong version" qu'avant, souvent inutiles (comme les warnings que PreOs génère à l'installation).

Toutes les routines d'une lib dynamique doivent etre presentes dans la calc, certes mais ou est le probleme ?

Que ça gaspille de la place si elles ne sont pas utilisées.

Un probleme tres embetant des librairies statiques, outre ceux deja explicites, est que : je vais prendre l'exemple de genlib en mode statique, si elle avait existe. 95% des fonctions sont liees entre elles (lors de l'initialisation, genlib reinit pas mal de choses en appellant les fonctions necessaires, et certaines fonctions de bases telles gl_set-dscreen_function font du self modifying code sur 80 % des fonctions).

Comment veux-tu réaliser ton idée de découpage de librairie dynamique en morceaux avec une librairie comme ça?
Et au lieu de convertir bêtement octet par octet ta librairie dynamique en librairie statique, adapte-toi aux besoins changés. Par exemple, au lieu d'utiliser du code auto-modifiant, utilise des variables globales dans un fichier objet commun à toutes les routines (qui ne devrait pas faire plus d'une trentaine d'octets et qui pourrait être combiné en un fichier objet avec les routines d'initialisation et de désinitialisation). Aussi, au lieu d'appeler toutes les fonctions lors de l'initialisation, écris un code compact (pas besoin de vitesse dans la routine d'initialisation) qui ne sert qu'à ça.

ceci rend un bloc static genlib inflexible, a disons 15 K.

Pas si tu rends ta librairie plus flexible, cf. ci-dessus.

Sur ma calc, je possede Cf, SMA, pokered et Total. 4 jeux necessitant genlib.

Tu la trouves où la mémoire archive pour ces 4 jeux ensemble??? Tu n'as que ça sur ta calculatrice?

Si c'etait une lib statique, chacun aurait du avoir sa version de la lib statique, et donc cela aurait fait 15K * 4 = 60 K de libraire genlib sur la calc. Comme c'est une lib kernel, elle ne prend que 18 k sur la calc, soit un gain de pres de 42 K, en evitant la redondance du code.

Déjà, avec mes optimisations, on en saurait à moins de 60 KO. J'estime 30-45 KO environ. Ensuite, avoue que ton cas (4 jeux utilisant la même grosse librairie, et utilisant une grande partie de ses fonctions) est un cas bien particulier, et très rare. N'oublie pas non plus qu'une librairie dynamique ne peut pas être compressée (du moins pas encore), et prend donc 50% de place en plus qu'une librairie statique. Enfin, n'oublie pas que le kernel lui aussi prend de la place.

Par ailleurs, je n'aurais a mettre a jour qu'un seul fichier pour corriger des bogues, et pas 4. Ce qui economisera un peu la memoire archive.

Tu en es vraiment à un cycle d'effaçage près?

Certes, cela impose qu'une lib dynamique est limite en taille (plus de 20 K ?) : il ne faut pas que ca soit trop gros. Donc avec une lib statique on peut multiplier les fonctions avec plein de methodes d'appels differents. Ceci est bien pour la performance. On peut s'adapter au cas par cas. Mais cela un effet pervers. Un programme peut grossir tres rapidement parce que le programmeur va utiliser plein de fonctions differentes.

Si c'est un bon programmeur, il s'en rendra compte tout de suite qu'il utilise trop de fonctions et que le programme devient trop gros.

Il va utiliser trop de fonctions differentes, et chacune d'entre elles va devoir avoir son code dans le programme final. Bref, la multiplication des fonctions est bien, mais ajoute le risque d'augmenter de maniere exedentaire le code final, sans reelle necessite (On aurait pu se debrouiller avec d' autres fonctions et donc utiliser seulement un sous-ensemble de celles-ci, pour obtenir un code plus petit).

Si c'est raisonnable, le programmeur le fera quand-même. Mais ce n'est pas forcément une bonne idée de se débrouiller avec peu de fonctions quand on peut en avoir plus.
Et tu oublies un argument important: le choix des fonctions. Par exemple, au lieu d'avoir une seule routine de sprites >16×16 (genlib), il y en a 16 dans ExtGraph:
Sprite32_* -> 4
SpriteX8_* -> 4
GraySprite32_* -> 4
GraySpriteX8_* -> 4
Il n'est évidemment pas question de les utiliser toutes les 16 dans le même programme! Mais le programmeur peut choisir celle(s) qui lui convien(nen)t le plus.

Un autre inconvenient des libs dynamiques est qu'il faut la charger completement. On ne peut pas (encore ? c'est en projet) charger une sous-partie de celle-ci.

Si tu veux faire ça pour genlib, autant la porter en librarie statique, tu dois faire exactement les mêmes transformations de toute façon.

Mais tout d'abord, je n'ai jamais entendu parler de problemes concrets. Souvent entendu en theorie, jamais demontre en pratique.

SMA et CF utiliseraient peut-être moins de RAM si les fonctions qu'ils n'utilisent pas n'étaient pas recopiées en RAM pour rien...

Ensuite, preos v0.58 supportera le package de libraries compressees : on pourra faire plein de sous libs dynamiques, que l'on compressera ensemble et reliera dans un seul fichier.

Et hop, encore 1 KO de plus dans PreOs...

PpHd
a écrit : Si Extgraph / xlib etaitent des libraries dynamiques ont economiserait pas mal de place.

Non, parce que personne n'utilise toutes les routines de ExtGraph. (Cf. l'argument de la flexibilité à travers le choix des routines ci-dessus.)

Ah ! Et alors ? tu connais le mot regression ? Le format Fargo etait vraiment bien foutu, et c'est encore mon prefere.

Ce n'est pas parce que c'est ton préféré que c'est le meilleur!

<< Si c'est seulement pour les librairies dynamiques que tu veux utiliser un kernel, j'ai déjà répondu plus bas. Ça n'apporte rien d'autre. >> Et pour economiser de la place.

Pas vraiment...

Si tu veux je peux faire, preos("monprog"). Ca sera pareil et ca marchera tres bien.

Fais nous la possibilité de faire un PreOs personnalisé pour chaque programme (qui lance automatiquement le bon programme) et ça deviendra intéressant. Mais ça gaspillera énormément de place par rapport à un simple programme _nostub.

Tu choisis la version que tu souhaites de preos. Perso, moi c'est 2.5 K installe en TSR.

Mais elle n'est pas compatible avec HW2 AMS 2, cette version!

Il fallait mettre a jour et faire abstraction du passe, pour repartir sur des bases propres.

Je ne trouve pas que le fait de rejeter gratuitement les librairies dynamiques sans numéros de version soit vraiment nécessaire à cette fin.

<< Non. Il y a beaucoup trop de fonctions inutiles pour que ça soit le cas. >> Exemples ?

graphlib::fill, graphlib::smallbox, graphlib::box, graphlib::frame, graphlib::clr_scr, graphlib::clr_scr2, graphlib::vert, graphlib::horiz, graphlib::bigbox, graphlib::line, graphlib::show_dialog, graphlib::clear_dialog, graphlib::erase_rect, graphlib::frame_rect, userlib::idle_loop, userlib::FindSymEntry, userlib::DrawCharXY, userlib::getfreeRAM, userlib::smallmenu, userlib::getfreearchive, userlib::set_APD, userlib::get_APD, ...

<< Je ne parle pas de "bouffage de mem", mais d'utilité de la librairie.
Et puis le cas de la librairie dynamique donne plus de "bouffage de mem", parce qu'il y a des fonctions de la librairie dynamique qui traînent inutilisées parce qu'on les a réécrites (puisqu'elles étaient inadaptées). >> La compatibilite des vieux programmes est elle un peche ?

Je ne parlais pas ici des fonctions inutiles qui restent pour la compatibilité, mais des fonctions utiles, mais inadaptées à un programme spécifique qui traînent inutilisées parce que le programmeur les a réécrites de manière adaptée. Relis-bien le contexte auquel j'ai répondu.

Le pire des idiots ne sera pas lancer le programme alors...
Et il aura autant de ttstart que de programme. A le gain, il est vraiment grand

Moi, je ne suis pas un idiot, et pourtant j'ai un ttstart par programme parce que c'est bien plus pratique!

Que veux-tu ? Je te conseille de prendre une femme de menage alors.

Et ziplib::compress ?

On peut utiliser la compression RLE on-calc de Greg Dietsche. Ou alors on attend qu'il ait implémenté d'autres algorithmes dans sa CompressLib (statique). C'est prévu.

Dommage que tigcc.a / extgrpah.a / xlib.a ne soient pas des libs dynamiques. On gagnerait beaucoup de place.

Non, parce qu'il y a beaucoup de fonctions très rarement utilisées dans TIGCCLIB et ExtGraph.

Nitro a écrit :
Je suis également 100% d'accord avec PpHd...
De plus j'ajouterais que le probleme kernel/nostub n'embete que les pro-nostub parce qu'ils n'ont pas de kernel et donc ne peuvent pas utiliser tous les programmes. Ceux qui ont un kernel n'ont pas ce probleme. J'ai fait le loader nostub pour genlib parce que ceux qui ne veulent pas de kernel ne pouvaient pas s'en servir.

J'ai un kernel sur ma TI-92+ en ce moment (PreOs-hw2tsr-tictex).
Ce n'est pas parce qu'on a un kernel sur sa calculatrice qu'on encourage la programmation en mode kernel, ni vice-versa.

J'espère que je ne me ferai pas bannir avec la quantité de messages que je viens de poster, mais il fallait bien que je réponde.

>"Parce qu'ils sont trop paresseux pour recompiler leurs programmes?"
je réponds juste a ça, pke ça dépasse vraiment tout
MDRRR t'as la flemme d'installer un kernel, tu donne comme argument contre les kernels que c'est chiant pke il faut les lancer, tu critiques les libs dynamiques parcequ'on doit les désarchiver, les renvoyer quand de nouvelles versions sortent, et pour toi c'est normal de devoir recompiler des progs entiers? rah c con, il faut les désarchiver et les renvoyer sur la calc... merdalor ça me rappelle quelquechose

C'est que je n'aime pas les programmeurs qui rabattent une partie de leur travail sur les utilisateurs. C'est au programmeur de mettre à jour une librairie, pas à l'utilisateur!