Martial Demolins (./28) :

Kevin Kofler (./24) :
(genre tout linker en un seul programme au lieu de développer 10000 plugins)

-9999 si no veut les relogements en flash, les ramcalls, et les variables. sinon, -10000.

Je parle de la technologie des programmes en morceaux là, pas de l'exécution en FlashROM. (Tu as proposé 2 technologies différentes, aussi inutiles l'une que l'autre.) Regarde bien le contexte de ce à quoi tu réponds!

(et les sauvegardes d'écran sur la pile (avec une routine même pas optimisée !))

La sauvegarde de l'écran sur la pile permet justement d'économiser de la mémoire heap! Quant aux histoires d'optimisation, ce n'est pas retirer 2 octets qui changera énormément les choses.

La place en archive, c'est minime, minime.

Pas tellement, fais le calcul, tu verras que toutes les tables d'importation et d'exportation prennent beaucoup de place que tu as l'air de croire.

Et justement, le but est de se servir de la flash pour économiser la RAM, et pas de la RAM pour économiser la flash

Et justement, c'est économiser au mauvais endroit. La RAM est de la mémoire de travail, tu as environ 150 KO minimum de libre en conditions normales, tant que tu n'utilises pas ces 150 KO (ou disons 100 KO pour être surs, c'est la quantité de mémoire nécessitée par TI-Chess par exemple), ça ne sert rien de l'économiser. L'archive, elle, est de la mémoire de stockage, plus tu consommes d'archive, moins de programmes l'utilisateur pourra garder sur sa calculatrice. Donc consommer 1 KO d'archive pour réduire la consommation de RAM de 100 KO à 1 KO est déjà un mauvais choix (ou le serait si c'était possible, en réalité l'overhead pour une granularité aussi fine serait immense!).

Quant au temps, j'ai déjà posté publiquement la routine (~50 lignes?) qui fait ça, ya plus qu'à coder autour sans rien changer.

Je sais que tu as déjà perdu ton temps, ça n'en fait pas moins du temps perdu.

C'est sûr, si tu t'amuse à charger 20 ko de code entre l'affichage de deux persos, ça va ramer. Kilukru Si c'est bien fait, tu n'y vois que du feu.

Ce n'est pas de ça que je parle, mais du fait qu'un saut relogé en abs.l (ou pire, du F-Line) est beaucoup plus lent qu'un bsr.w voire bsr.s qu'on aurait en général dans un programme monolithique (surtout grâce à --reorder-sections). Mais effectivement, il y a le temps de chargement/déchargement aussi.

CF, oui.

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.) Mais ce n'est pas le genre de programmes qu'un nouveau programmeur comme imane va coder.