1

Je pense realiser bientot (Lorsque je reprendrai le developpement de CF) une nouvelle librairie (Ne pleure pas Kevin) : cachelib !

Son but est simple : offrir un acces rapide aux libraries en les cacheant en memoire. Une utilisation typique dans CF engine v4.00 verra le tot de libraries utilisees d'environ 40 a 50 par frame, ce qui est enorme, et preos est incapable de survivre a une telle demande en libraries dynamiques (entre le code conditionnele qui declenche des evenements, donc un chargement du code d'une librairie et les graphiques / les maps qui seront eux aussi en temps que librairies - Flemme powa). Il me faut dont creer une surcouche permettant un acces rapide aux libraries, ie un cache pour les librairies.

>> void cachelib_init (unsigned long n);
Initialise cachelib : alloue un cache (fixe) avec n entrees et installe le nouvel handler de ROM_THROW.

>> void cachelib_clear ();
Vide le cache et le detruit. Et enleve le HANDLER de ROM_THROW.

>>LIB *cachelib_lock (const char *libname, unsigned short version);
Verouille une entree dans le cache pour qu'elle ne soit pas videe si necessaire (L'ajoute si elle n'est pas deja dans le cache) ou retourne NULL si echec.

>>void cachelib_unlock (LIB *libref, clock_t time);
Deverouille une entree dans le cache pour qu'elle soit videe si necessaire et met a jour le temps de dernier acces du cache.
Ne fait rien si libref n'est pas dans le cache.

Le nouvel handler de ROM_THROW interceptera tout demande a une fonction memoire (HeapAlloc*), verifie qu'elle est satisfaite, et si elle n'est pas satisfaite, vide le cache pour essayer de la satisfaire (Donc reappelle la fonction). Ceci s'integrera parfaitement dans PreOS. L'application quand a elle devra utiliser les ROM_THROW pour les appels memoires pour que la cache soit effectif (ce qui n'est pas genant).

A noter que j'ai pense l'integrer directement dans Preos (ca serait genial top surtout avec un systeme de relocation paresseux) - ie le lancement d'un second txtrider serait instantanne - mais AMS n'est pas assez evolue pour que je le fasse proprement puisqu'il me faudrait intercepter TOUS les appels a HeapAlloc* (par contre dans PedroM ca serait possible love).

2

3

C'est un euphémisme pour "leak de mémoire". Il laisse traîner toutes les libs en RAM pour éviter de devoir les recharger plus tard, il ne les vire que s'il ne reste plus de RAM.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

4

bah nan, c'est pas un leak de mémoire, vu que c'est volontaire et que la mémoire n'est pas perdue triso
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

5

Et sous Linux, c'est effectue par default (un demon s'en occupe).

6

Le problème s'est est ce que ca vaut la peine d'en faire une lib vu que ce sera probablement CF only
avatar

7

Oui parce que ca obblige a etre beaucoup plus rigoureux dans son ecriture. Et puis c'est loin d'etre loin CF only.

8

9

J'avais prevu de la commencer a partir de Janvier (Mais bon je suis en retard).

10

11

Ben si les donnees RAM sont encapsuler derriere une LIB, pas de probleme triso
(Peut etre que j'essairais de faire un peu plus flexible, mais bon).

12

13

14

Ben je ne sais plus trop. Peut etre que je vais faire seulement pour CF smile

15

16

Je verrai.

17

18

Disons que ce n'est pas une prioritee

19

20

Comment reconnaitre les donnees statiques qui varient pas beaucoup ?

21

22

Oue mais ils ont droit a une MMU eux !!!!

23

24

25

ben comment tu veux intercepter les lectures/écritures mémoires ?

le but d'une MMU, c'est pas permettre le multitache, on peut tres bien en faire sans MMU, c'est intercepter les accès mémoire; ce qui veut dire qu'on peut protéger des zones de la mémoire, qu'on peut se passer en partie de relocations (en mappant l'adresse physique variable du programme à une adresse virtuelle fixe), qu'on peut avoir de la mémoire virtuelle (en lançant une exception pour les accès mémoire à des données qui sont en swap), etc...
donc meme pour un système mono-tache, ça peut permettre un système tolérants aux crash, ça peut permettre d'écrire un émulateur en mappant l'espace d'adressage de l'architecture émulée sur une adresse physique pour le système sur lequel tourne l'émulateur, bref ca pootramort happy

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

26

Les HP-49G+ ont une MMU, et ils auraient pu faire pire pour le processeur central, l'ARM étant un RISC, mais un bon.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

27