yop,


Toujours omnubilé par l'exécution archive économisatrice de RAM, il m'est venu une idée ce matin.
Les ramcalls en fline ont permis l'immense progrès qui consiste à exécuter un programme en flash en utilisant les ramcalls, et par conséquence, les dll chargées par le programme via kernel::Libs*.

Inconvénient : il faut un trampoline dans la pile (une table de 'jmp xxx', méthode la plus rapide en terme de vitesse d'appel) pour accéder aux fonctions désirées dans une DLL quand on a besoin d'une fonction. Je précalcule toutes les fonctions qui me sont nécessaires à l'avance, donc le travail n'est fait qu'une fois à l'init, mais c'est quand même pas optimal, particulièrement dans le cas où une dll RO doit appeler une autre dll RO : la première dll doit, à chaque appel qu'on lui fait, faire un LibsBegin sur la seconde lib et récupérer les adresses, ça peut plomber les perfs d'un programme qui a besoin de vitesse (Par fait ça mais il n'a pas de besoin critique de vitesse).

De plus, ce mode de programmation a un inconvénient : interdiction d'utiliser des appels relogés pour les dll, les romcalls, interdiction des BSS et des relogements internes (en adresses absolues). Hors malheureusement, ce sont les appels les plus efficaces en terme de vitesse.


La solution que j'ai imaginée :
Si le programme a des adresses à reloger (relogement de dll, de romcall, relogement absolu, bss, ramcalls)
- On regarde si l'archive dispose d'une place pour le programme à exécuter. On récupère l'adresse de cette place
- On reloge le programme en RAM en fonction de sa future place
- Une fois relogé, on pousse le programme en archive, à la place convenue.

Et voilà. Si on regarde, on y gagne, pour l'exécution en archive :
- les ramcalls relogés (gain en vitesse)
- les dll calls relogés (gain en vitesse et en simplicité de programmation)
- les relogements des adresses absolues (gain en vitesse)
- les BSS (variables globales).


A noter que la section de code ne doit contenir aucune section de donnée non RO pour des raisons évidentes. Mais grâce aux BSS (dans lesquelles TIGCC met les variables globales), on retrouve l'accès à des variables globales qu'on avait perdu avec l'exécution en archive actuelle.

Les programmes susceptibles de recevoir un tel traitement par le kernel seront les programmes portant le flag RO actuel :
- aucun programme RO existant actuellement ne sera relogé à nouveau, le kernel voyant qu'il n'y à aucune table de relogement à traiter
- un programme RO contenant des tables de relogement sera transféré en RAM si nécessaire, relogé, puis poussé en archive



Voilà, c'est pas beau ça ? Immaginez un jeu de 64 ko qui utilise une lib de 64 ko de code + données statiques.
Sur AMS, il lui restera ~70 ko de RAM pour ses plans, sprites, maps et compagnies.
Avec cette méthode de relogement, il tourne avec une RAM vierge. Encore une fois, le programme dispose intégralement de la RAM quelque soit sa taille.
Qui plus est, ça permet de coder sans la moindre complication, sans aucun des inconvénients de la méthode de programmation actuelle ! On peut coder vite sans se prendre la tête pour un adressage foireux.

A noter également que les programmes RO deviendront possibles en C. En effet, on ne maitrise pas le moindre octet de son binaire final comme en ASM, surtout quand TIGCCLIB contient des paquets de relogements, donc c'est très difficile (et vraiment très chiant) de faire du RO en C.