4Fermer6
deleted2Le 19/11/2010 à 16:23
PpHd (./2) :
Très bonne idée, j'y ai pensé, mais

Je m'en doutais à vrai dire.
PpHd (./2) :
quid de l'usure accélérée de la mémoire Flash ?

D'après WP ( http://fr.wikipedia.org/wiki/M%C3%A9moire_flash ), on peut tabler sur 10k fois minimum, et au mieux jusqu'à 100k. Je doute qu'on en arrive là, comme je doute qu'on tourne toujours dans le pire des cas. Ce qui veut dire qu'un programme sera mis en flash x fois avant un garbage. Qui plus est, je ne sais pas qui a lancé un même programme déjà 10k fois sur TI...

Possibilité pour reloger encore beaucoup moins que par la méthode brute (reloc à chaque run) :
- on met à un le flag 7 (non utilisé) d'un programme en flash.
- s'il utilise des libs RO, alors on vérifie qu'elles n'ont pas bougé (même test de flag).
- s'il utilise des librairies à exécution classiques (Genlib), on essaye de reloger la lib à la même place en RAM (là ça se complique, faut manipuler le heap à la main).

Côté utilisateur :
- Le kernel peut, par défaut, faire tourner les programmes à relogement en RAM. Avec un flag, il sait qu'il peut envoyer les programmes en archive.
- On peut fournir un petit utilitaire qui dégage le flag RO des programmes à relogement.

Ces mesures peuvent diminuer beaucoup l'usure, voire la supprimer si l'utilisateur le veut.



squalyl -> non, BSS == relogement. Ta vraie solution ne marchera pas, parce que pc-relatif == offset de 32ko max. Et en archive, tu peux pas adresser la RAM de là. Et pour un programme de 64 ko, c'est foutu d'avance.

Pen^2 -> C'est ce que je propose aussi, encore faut-il que des éventuels appels à des dll non RO soient vérifiés, voire remis en place.
Et en général, les BSS contiennent les vars globales, qui, dans un programme bien codé, ne devraient pas prendre trop de place (1ko de vars c'est déjà énorme).