Pour tuer la guerre _nostub/kernel - Page 1

Le meilleur (car valable) argument des défenseurs du _nostub c'est que la combinaison prog+kernel+libs dynamiques demande plus de mémoire que le mode prog+fonctions utilisées.

Ainsi j'expose ma modeste proposition qui retirera cet argument de leur arsenal :
Diviser les librairies dynamiques en plusieurs parties.
Cette division n'est pas faite au hazard, mais de façon à regrouper les fonctions les plus utilisées dans la "sous-lib" n°0, celles un peu moins utilisées dans la "sous-lib" n°1, ...

J'en vois certains qui se disent "ça va être le bordel à programmer".
Ben non ! Prenons l'exemple de genlib. Dans la "sous-lib" n°0, on trouverait des fonctions telles que genlib::init, et dans la numéro 1, les fonctions telles que genlib:: put_big_sprite_flip_hv. Ce fractionnement sera totalement transparent au programmeur, car quel que soit le fichier où se trouve la fonction, il écrira toujours genlib::init ou genlib:: put_big_sprite_flip_hv...

Le seul qui va avoir du boulot est le réalisateur de la lib : il devra modifier son .h (en plus du fractionnement de son code ) :
genlib::init EQU genlib0@0000
genlib:: put_big_sprite_flip_hv EQU genlib1@0017


Le point noir c'est les variables internes de la lib, mais il y a toujours une solution : par exemple en les adressant par un registre (a6 par exemple). Au début de chaque fonction on fait move.l #souslib0:: DebutDesVars,a6. C'est pas le peu de cycles que ça prend...
[edit]Edité par Thibaut le 08-08-2001 à 18:57:00[/edit]

pas bête !

C'est ce que font les librairies statiques, mais imagine-toi le bordel que ça ferait avec les librairies dynamiques! "Missing sub-lib 0001 of genlib", "Missing sub-lib 000a of graphlib" ...
Et puis, je ne te raconte pas la taille que prendrait le kernel qui gèrerait tout cela. Et le "Lib Receiver" (non, ce n'est pas une faute de frappe).

Je me suis mal expliqué. On garde le format des libs actuelles. Le terme sous lib était bien entre guillemets.

La différence, c'est qu'au lieu d'avior une lib à envoyer sur sa calc, on en a plusieurs. C'est tout

>Thibaut: La différence, c'est qu'au lieu d'avior une lib à envoyer sur sa calc, on en a plusieurs.

Encore plus???
Pourquoi semer le bordel d'une telle manière?
Le nombre de handles et donc de fichiers de la TI-89/92+ est limité. Pourquoi l'agrandir inutilement?
Aussi, un nombre plus important de fichiers ralentit toutes les opérations sur les variables.
Et puis imagine: "Missing lib: genlib1", "Missing lib: graphl10", ...
On ne s'y retrouve plus!
Enfin, un nombre plus important de librairies dynamiques veut non seulement dire un nombre plus grand de fichiers (une vingtaine d'octets par fichier), mais aussi un nombre plus grand de stubs kernel (une cinquantaine d'octets par fichier).
Les micro-libs dynamiques que tu proposes risqueraient de prendre plus de place pour les stubs et la gestion des handles que pour les fonctions elles-mêmes!
De plus, la table de relogements d'un programme en mode kernel prend 10 octets supplémentaires pour chaque nom de librairie. Si genlib était fractionné en 10 librairies dynamiques, on perdrait 90 octets par programme qui l'utilise!

Les librairies statiques sont beaucoup plus pratiques.
[edit]Edité par Kevin Kofler le 08-08-2001 à 20:05:19[/edit]

Thibaut: Desole, j'y ai deja pense, mais je pense pas que ce soit valable qvec le format actuel.
Et pour enterriner cet argument, suffit de se rendre compte que seul qq programme au singulier a un reel besoin de memoire vive.
Tant qu'on est sous la limite, ca sert a rien.
Et pour finir, Genlib restera dynamique puisque Chrono depasse les 55Ko de programme quasiment put (Y'a rien que les jumps tables), et donc que je peux pas implementer genlib statiquement :P

Solution simple: tu fais une version statique et pour les gros programmes comme Chrono qui utilisent pratiquement toute la librairie une version dynamique en _nostub sous le modèle de FATLib.

Et puis ne me dis pas que tu n'es pas capable de faire une version adaptée de ttstart pour lancer des PPGs à 2 sections + des routines d'interfaçage entre les 2 sections du PPG spécial.

Oui mais ca fait du boulot en plus alors que tout est deja pret. Pourquoi devrai-je refaire ce qui existe deja ?

et pour les gros programmes comme Chrono qui utilisent pratiquement toute la librairie une version dynamique en _nostub sous le modèle de FATLib
C'est vraiment de l'acharnement

mais s'il a pô envie

Il ne jouera pas a Chrono, tant pis.

pphd: t'as pas le choix !

Arretez de defendre tel ou tel mode de programmation.
Ils ont chacun leurs avantages, et leurs inconvenients.
Et puis les histoires de taille en memoire, ca se vaut, sauf qu'il y a le noyau de kernel en plus en RAM.

Franchement, c'est ridicule.
Cependant, je prefere le nostub, et ce pour une raison majeur : plus de FAQ !

Regardez un newbie : il a juste a envoyer le programme, et a l'executer.
Un prog en mode Kernel, il faut que le newbie telecharge le kernel, l'installe, cherche les bonnes libs, et surtout les bonnes versions (regardes le nb de pb qu'on les newbies avec SMA !!)

Nan sans dec, arretez...

moi aussi j'ai eu le meme probleme

mais en parlant de lib et de kernel !
Comment fait on pour detecter si un kernel a été installé ? Il doit bien y avoir une adresse magique ou qqchose comme ça ?

>FZ:regardes le nb de pb qu'on les newbies avec SMA
Ben c'est finis maintenant. C'etait au debut.
>-godzil: C pas a cause de pk, c un autre pb.

Pfffff ... Cette discussion n'a pas lieu d'être ...

Le problème se pose en termes bcp plus simples :
Personne n'est obligé de programmer. Chrono est un énorme boulot que PpHd et etan (je ne parle ici que des codeurs) NE SONT PAS OBLIGE DE FAIRE. Ca ne va leur rapporter strictement rien.

Ce qui leur donne le droit de programmer COMME ILS LE VEULENT. C'est simple : ceux qui ne sont pas d'accord ou qui préfèrent le _nostub ne joueront pas à Chrono, c'est tout.

De plus, ça doit être très démotivant, de voir tout le temps des topics de ce genre.

Tu peux comprendre ça, Kevin, non ?

Et là je ne développe qu'un aspect de la question, mais le principal.

Le problème du choix effectif entre stub / nostub est, au niveau technique, moins important. Je suis très certainement un codeur nettement moins bon que toi, Kevin, mais personnellement, installer un Kernel ne m'a jamais posé de problème. Et au newbies non plus. Aux lamerz, peut-être, mais tant mieux.

De toute manière, l'aspect technique est en définitive moins important que la volonté des codeurs. Je sais, je me répète, mais le programmeur n'est pas obligé de coder. Et vu qu'il le fait, et que cela lui coûte, je pense qu'il a le droit de choisir la façon dont il va programmer SANS QU'ON LUI CASSE LES COUILLES NUIT ET JOUR.

Ca me parait simple à comprendre, non ?

Heu ,et mon histoire de kerner

Cependant, je prefere le nostub, et ce pour une raison majeur : plus de FAQ !

Regardez un newbie : il a juste a envoyer le programme, et a l'executer.

Et la limite logicielle des 8/24 ko, tu en fais quoi ? Il me semble que tu est parmi les premiers à la dépasser et dans ce cas, le programme seul ne suffit pas.

Comment fait on pour detecter si un kernel a été installé ? Il doit bien y avoir une adresse magique ou qqchose comme ça ?

Oui, c'est dans les docs de DoorsOS !!

justement j'étais en train de les lire hier soir mais la fatigue m'a emporté dans son endroit magique qui est le sommeil

ParadiZe, va jouer ailleurs.
Tu es con, c'est ton probleme, je ne vois pas trop le rapport avec ce topic.

Et JM, je pense que tu as compris qu'il etait con donc tu ne lui repondras pas



Renorems : ce que tu n'as pas compris est que LES PROGRAMMEURS QUI FONT DU NOSTUB NE FONT PAS CHIER CEUX QUI FONT DU STUB, MAIS C'EST LE CONTRAIRE : CE SONT CEUX QUI FONT DU STUB QUI FONT CHIER CEUX QUI FONT DU NOSTUB
Qui a cree ce topic ? Thibaut, militant pour le mode Kernel...
Et puis sans dec, est-ce que j'ai deja critique les gens qui codaient en mode kernel ??

Nan mais !


Et JM : le pb des 8/24Ko n'est pas un pb : il y a les lanceurs qui s'en occupent parfaitement, tous mes programmes sont compresses (pour un gain de 50% de taille, les graphismes se compressent tres bien)

Au fait, Flash Savior c'est bien, mais si le kernel a ete perdu par la recuperation des donnees, on ne peut pas utiliser FlashSavior, donc impossible de recuperer les donnees...

>LES PROGRAMMEURS QUI FONT DU NOSTUB NE FONT PAS CHIER CEUX QUI FONT DU STUB, MAIS C'EST LE CONTRAIRE : CE SONT CEUX QUI FONT DU STUB QUI
>FONT CHIER CEUX QUI FONT DU NOSTUB
Tourne 7 fois tes doights autour du clavier avant d'ecrire.
>Flash Savior c'est bien, mais si le kernel a ete perdu par la recuperation des donnees,
Et si FlashSavior est perdu ?

Ca c'est encore autre chose.
Autant refaire Archive Utility.

Et je n'ai pas besoin de tourner 7 fois mes doigts avant d'affirmer une telle chose.

Qd est-ce que j'ai critique le kernel ?
Simplement qd on fait des remarques sur le nostub, je le defends.
Meme si j'ai tendance a faire de plus en plus de nostub, je fais aussi bien des progs en mode kernel.

Je t'ai critique sur ton affirmation, pas sur ta personne.

>tous mes progs sont compressés : en mode kernel il y a runc

HAAAAAAA HORREUR que d'inepties.
>>Au fait, Flash Savior c'est bien, mais si le kernel a ete perdu par la recuperation des donnees, on ne peut pas utiliser FlashSavior, donc impossible de recuperer les donnees...
La nouvelle version de FLS sauvegarde la VAT dans un segment réservé de la ROM. En cas de perte totale de l'archive, il suffit de retransférer FLS + le kernel, et on peut tout récupérer !

Ceci est dit dans le readme... FlashZ t'es un LamerZ (Humour, je précise, sait-on jamais)
[edit]Edité par Thibaut le 09-08-2001 à 17:16:53[/edit]

LES PROGRAMMEURS QUI FONT DU NOSTUB NE FONT PAS CHIER CEUX QUI FONT DU STUB, MAIS C'EST LE CONTRAIRE : CE SONT CEUX QUI FONT DU STUB QUI FONT CHIER CEUX QUI FONT DU NOSTUB
Qui a cree ce topic ? Thibaut, militant pour le mode Kernel...

hum faut quand meme pas exagerer... thibault est bien compensé par kevin
[edit]Edité par Elendur le 19-08-2001 à 17:51:20[/edit]

Je n'ai jamais créé un topic pour critiquer le mode kernel. Le seul topic dans lequel il y a eu ce débat et qui avait été ouvert par moi était l'annonce de la sortie de ExtGraph, qui n'était pas censée offenser les programmeurs en mode kernel.

Ok PpHd

Ouais, je crois que c'est evident
Nan sans dec on fait ce qu'on veut. Je ne crois pas qu'il y ait d'autres applications.