PpHd (./41) :Kevin Kofler (./29) :Tu veux essayer de tenir ton pari ?
CF utilise la mémoire (aussi l'archive) de manière totalement abusive, je sais. (AMHA, optimiser en taille plutôt qu'en vitesse pourrait réduire de beaucoup cette consommation.)
Vu qu'il faudrait essentiellement reconcevoir CF (y compris genlib) depuis le départ (c'est entièrement conçu pour la vitesse au dépens de la taille), je n'ai pas du tout le temps.
Rien que genlib aurait besoin d'une réécriture d'une grande partie du code (genlib-small est tout sauf optimale en taille).Lionel Debroux (./45) :
Le SMC qui permet parfois de bons compromis entre optimisation taille et optimisation vitesse
Voire de l'optimisation taille tout court dans certains cas.
Martial Demolins (./51) :
C'est pas que ça. si tu veux overlaoder ton programme pour qu'il sache décompresser, s'adapter aux AMS et aux HW, trouver et utiliser des fichiers de données etc, tu peux, mais ça bouffe de la place à chaque fois.
Le lanceur-décompresseur prend 1 KO seulement (grâce à ttunpack-small, merci à Samuel Stearley!), et en plus un lanceur-décompresseur commun peut être utilisé, donc c'est un très mauvais argument. La consommation de place pour la compatibilité avec les différents AMS/HW est minime, quant aux fichiers de données, les fonctions nécessaires sont déjà dans AMS (vat.h), donc je ne vois pas de quelle consommation de place tu parles là. (De plus, le kernel ne propose rien pour les fichiers de données, à part l'abus du système de librairies conditionnelles de PreOs.)
Martial Demolins (./53) :
Par contre, c'est lourd (regarde la manière dont AMS est détecté dans PreOS par exemple).
Un programme normal n'a pas besoin de détecter AMS de cette manière, PreOs contient ces détections pour faire marcher les RAM_CALLs qui servent à faire marcher les programmes bogués qui utilisent des hacks obsolètes (et d'ailleurs, souvent, un réassemblage de ces programmes est nécessaire pour les faire utiliser les nouveaux RAM_CALLs plutôt que les anciens hacks avec des adresses ou des offsets codés en dur).
Martial Demolins (./57) :
dépendances? tu parles du seul et unique fichier de lib à envoyer?
Non, il parle des versions toutes incompatibles des libs en circulation.
* stdlib ne pourra jamais regrouper toutes les libs utilisées.
* Rien ne garantit que tous les programmes sont compatibles avec les versions dans stdlib.
* stdlib est une solution "bulldozer" au problème, on gaspille 20 KO (compressés en plus) pour fournir toutes les libs qu'un programme pourrait utiliser, même si aucun programme n'utilise ne serait-ce qu'une seule fonction de certaines de ces libs. (Par exemple, qui utilise réllement jplib?)
Rien que genlib aurait besoin d'une réécriture d'une grande partie du code (genlib-small est tout sauf optimale en taille).
Il y a par exemple triglib dans stdlib qui est peu ou pas utilisée. genalib aussi (CF l'utilise, mais à part ça?). Et ugplib.
Je ne vois pas pourquoi ce serait différent avec un kernel::LibsBegin. Il y a des APIs plus adaptées pour les fichiers de données (vat.h en l'occurrence).
Coup de chapeau quand même à tes routines, j'en ai lu une bonne partie.
