ExtendeD
a écrit :
Malheureusement la plupart des _nostubiens pensent comme toi (ie une lib statique ou un patch qui prend pas trop de place dans un porgramme, c'est bien). Mais si par exemple on regarde ces valeurs (j'utilise TIGCC 0.94 beta 11, et j'espère ne pas m'être planté dans le calcul):
Bon, on y va (je recompte tout à la main, j'espère que je ne me trompe pas):
>routines de gray : 948 octets
J'ai compté 932 octets.
>enter_ghost_space : 120 ocets
J'ai compté 112 octets.
>exit_support : 24 octets
Si tu comptes le push/pop des registres à part (cf. ci-dessous), ça ne prend que 6 (code) + 4 (reloc) = 10 octets.
Et même avec le push/pop, on n'en est qu'à 18 octets.
>save_screen : 48 octets
Là, c'est bon, je trouve la même chose.
>AMS_check : 48 octets
C'est bon, je trouve 22 (code) + 26 (message) = 48 octets.
>calc_detect : 32 octets
D'où sors-tu ça? De ton implémentation optimisée? Moi, je trouve 46 (code) + 24 (message) = 70 octets dans le meilleur des cas.
>push/pop des registres
: 8 octets
Oui.
Et il manque: "complex_main" (
jbsr _main et
rts au lieu de
jmp _main): 2 octets (pour le
rts).
Si on imagine maintenant une calc avec:
10 routines de gray
5 enter_ghost_space
20 exit_support
20 save_screen
25 AMS_check (si c'est pas le cas maintenant ça le sera bientôt)
20 calc_detect (pareil, mais en enlevant les progs compatibles on-calc)
30 push/pop des registres
-> 13600 octets perdus un peu pour rien.
Moi, je trouve 12980 (en rajoutant les 2 octets du
complex_main au push/pop des registres).
Et
calc_detect concerne aussi les programmes compatibles on-calc puisque c'est utilisé pour calculer
CALCULATOR. Mais il faut aussi tenir compte du fait que ces programmes contiendraient de toute façon le code de détection, et même à plusieurs endroits, alors que là, il n'y est plus qu'une seule fois.
Même si tout est compressé, à ce prix là, on peut s'offrir PreOS (en tout cas l'argument de la taille n'est plus vraiment un argument pour les nostubiens).
1. Déjà, à part
enter_ghost_space, tout se compresse avec
ExePack, qui réduit la taille à 2/3 environ, donc on n'est plus qu'à (12980-5*112)*2/3+5*112=8840 octets.
2. Tu oublies les 50 octets minimum pris par le header des kernels dans chaque programme: ça fait déjà 50*30=1500 octets, donc la différence n'est plus que de 7340 octets.
3. Tu oublies aussi le stub des programmes pour kernel qui prend lui aussi 44 octets dans chaque programme (sauf si on n'affiche pas de message d'erreur "Kernel needed", ce qui est est vraiment une saleté): ça fait déjà 44*30=1320 octets, donc la différence n'est plus que de 6020 octets.
4. Rajoute la taille de
graphlib, sans laquelle tu ne peux pas légitimement compter les routines de niveaux de gris intégrées comme du gaspillage: ça fait 2565 octets (
gray4lib ne fait que rediriger vers
graphlib, et
genlib est encore plus grosse, donc c'est le plus petit que je pouvais compter), donc la différence n'est plus que de 3455 octets.
5. Or,
PreOs prend 5317 octets, donc le
_nostub a épargné 1862 octets.
Je sais bien que les nombre de routines sont peut-être un peu surestimées (quoiqu'il doit bien y avoir des calcs qui ont cette tête), et que dans /C ont pourra que me taper dessus, mais une centralisation des patchs ne feraient quand même pas de mal.
Tu veux les "centraliser" où???
Enfin, moi je constate. Si on ne laisse pas le programmeur activer lui-même les patchs qu'il veut, on risque bientôt de voir des listes comme ça de plus en plus longues.
Ça prend toujours moins de place que le mode kernel. Cf. mes calculs ci-dessus.
