Calculer la RAM utilisée par un programme - Page 3

Oui, ça marche bien, et pas besoin d'un kernel... Il y a toujours des solutions optimisées sans kernel.

Ta routine a le merite d'etre tres lente.

Si tu l'appelles depuis l'extrême fin du twin, oui. Si tu l'appelles du début, pas tant que ça...

Au pire, tu en as pour : 20 (cycles environ) * 2000 (handles) * taille de ton programme/2.
Soit pour un prog de 30Kb:
40.000 * 15.000 = 600.000.000, soit environ 1 minute

argh

PpHd a écrit :
Au pire, tu en as pour : 20 (cycles environ) * 2000 (handles) * taille de ton programme/2.
Soit pour un prog de 30Kb:
40.000 * 15.000 = 600.000.000, soit environ 1 minute

Comme le dit XDanger, ça dépend de l'endroit duquel on part. Si on met ça au début d'une fonction qu'on met tout en haut du premier fichier source, ça va aller très vite.

Pas tres vite. Y'aura deja de 500 a 1000 octets avant. Soit quand meme environ un peu moins d'1 seconde

Kevin & XDanger > Merci
(j'ai plus qu'à méditer là dessus pour voir ce que ça fait exactement )

[Edit] :

Kevin Kofler a écrit :

void *p; HANDLE h;
asm("lea 0f(%%pc),%0; 0:"=a"(p));
p&=0x3ffff;
while(!(h=HeapPtrToHandle((p-=2))));
printf("Memory required by twin: %lu",HeapSize(h)+sizeof(SYM_ENTRY));

Heu... Il manque un " dans la ligne ASM, je le mettrais bien entre 0 et :, mais je ne connais absolument pas ce genre d'appels. De plus, TIGCC refuse l'operation "p &= 0x3FFFF" (invalid use of & ), je ne vois pas trop pourquoi

Bon, j'ai corrigé mon code (cf. édition du message). Il compile maintenant, et devrait marcher. Mais j'ai encore mieux (on cherche un petit peu moins longtemps):

void *p; HANDLE h;
asm("0: lea 0b(%%pc),%0":"=a"(p));
(unsigned long)p&=0x3ffff;
while(!(h=HeapPtrToHandle((p-=2))));
printf("Memory required by twin: %lu",HeapSize(h)+sizeof(SYM_ENTRY));

(remarque le label avant le lea plutôt qu'après).

Ok ça marche, ça indique donc la taille que prend[rait] le twin ?
Donc il suffit de tester le flag twin (en esperant que PPG l'arme) pour savoir si il faut oui ou non compabiliser cette taille.

Les extracteurs PPG ne créent pas du tout de twin, juste un handle (par conséquent, la taille prise est seulement HeapSize(h) et non pas HeapSize(h)+sizeof(SYM_ENTRY) dans ce cas).

Et, j'oubliais: dans tous les cas, il faudrait aussi rajouter 16 à la taille calculée parce que c'est la place prise par le header du handle, qui se rajoute donc à HeapSize.

Ah... Pas de twin... Donc impossible de reconnaitre à partir de ce handle qu'il appartient à une variable décompressée
Moi qui comptais faire ça avec des pointeurs SYM_ENTRY, c'est raté

Bah, on peut voir qu'il n'appartient pas à une variable, et qu'il est donc un handle temporaire créé par ttstart ou semblable.

Pourquoi on ne peut pas effectuer d'opération sur un pointeur ? (p&=0x3FFFF)

Parce qu'on ne peut pas. On ne peut faire que + et - sur un pointeur, et même là, on est limités (pointeur + pointeur n'est pas permis, par exemple).
De toute façon, les "lvalue casts" de GCC (http://tigcc.ticalc.org/doc/gnuexts.html#SEC70, c'est ce que j'ai utilisé dans mon code) règlent ce problème très facilement.

C'est bizarre quand même...

Quel sens a-ce de prendre une adresse AND un nombre? Ça a un sens sur notre machine bien particulière où des adresses fixées ont un fonctionnement bien fixé, mais sur une machine générique, c'est carrément n'importe quoi. Et d'ailleurs même l'assembleur 68k ne prévoit aucune instruction pour adresse&=nombre, il faut commencer par placer l'adresse dans un registre de données. Le transtypage vers un type entier y correspond parfaitement.

Je m'attendais à ce que quelqu'un fasse une réflexion sur la lenteur de la routine de Kevin, mais je ne pensais pas à PpHd... Il n'y a besoin d'appeler cette routine qu'une fois, donc même si elle est assez lente, ça n'est pas un énorme problème, dans la limite des quelques secondes.
Et tu as encore pris un pire cas pour donner un bench, ça prend 2 secondes environ s'il y a 1000 octets avant le test...

Je rappelle que j'ai posté un lien vers une méthode qui est exactement la même que celle postée par PpHd, qui sera ajoutée dans TIGCCLIB et qui ne nécessite pas de kernel...
Ptr2Hd sera ajoutée dans TIGCCLIB également. Kevin a répondu "Why not ?" à ma suggestion, c'est à dire en gros "oui", car s'il n'était pas d'accord il l'aurait dit franchement et il aurait dit pourquoi (c'est ce qu'il avait fait pour ma suggestion de faire une version de _rowread qui aurait pour deuxième paramètre le temps d'attente).

Dans ce cas on pourrait faire appel a la fonction du kernel si on compile en kernel ?
(Je connais deja la reponse).

Déjà, rien ne dit que les fonctions dans TIGCC auront les mêmes noms que les fonctions dans ton header kernel non officiel...
Et puis si tu prétends connaître la réponse, pourquoi postes-tu, alors ?

pkoi vous ignorez toujours une partie des codeurs ?
surtout que 2 secondes c'est qd meme assez lent, non ?

solid: je ne me prononcerai pas, car je ne suis pas sûr de la position exacte de PpHd là-dessus...
Je ne suis pas sûr que lui, il ait envie de mettre son header dans TIGCCLIB (que la TIGCC Team mette son nez dans son propre boulot à lui, quoi). Elle serait sans doute trop pénible et l'empêcherait de faire tout ce qu'il veut dans son propre truc propriétaire incompatible sur plein de points avec les kernels antérieurs - incompatibilités parfois ajoutées bêtement.

XDanger a écrit :
Je rappelle que j'ai posté un lien vers une méthode qui est exactement la même que celle postée par PpHd, qui sera ajoutée dans TIGCCLIB et qui ne nécessite pas de kernel... Ptr2Hd sera ajoutée dans TIGCCLIB également. Kevin a répondu "Why not ?" à ma suggestion, c'est à dire en gros "oui", car s'il n'était pas d'accord il l'aurait dit franchement et il aurait dit pourquoi (c'est ce qu'il avait fait pour ma suggestion de faire une version de _rowread qui aurait pour deuxième paramètre le temps d'attente).

Sauf que la routine que tu indiques n'est pas un Ptr2Hd valide. Il marche seulement avec les variables dans la VAT! C'est prévu seulement pour SET_FILE_IN_USE_BIT. Ça ne marchera pas du tout avec un handle pris au hasard! Celui d'un programme décompressé par ttstart, par exemple.
Il faut passer par une boucle avec HeapDeref et HeapSize (ou alors HeapTable (ROM_CALL #0x441 sous AMS 2, hack nécessaire sous AMS 1)), pas avec SymFindFirst et SymFindNext.

PpHd a écrit :
Dans ce cas on pourrait faire appel a la fonction du kernel si on compile en kernel ? (Je connais deja la reponse).

Non, parce qu'elle est PreOs-only.

solid a écrit :
pkoi vous ignorez toujours une partie des codeurs ?

On ne vous ignore pas du tout. Le format kernel continue à être supporté, avec exactement les mêmes fonctionnalités qu'en _nostub.

surtout que 2 secondes c'est qd meme assez lent, non ?

On peut faire nettement plus rapide que ma routine sans kernel. (Il suffit d'utiliser le même algorithme que PreOs.) Ça prendra juste quelques octets en plus.

XDanger
a écrit : Je ne suis pas sûr que lui, il ait envie de mettre son header dans TIGCCLIB

Même s'il voulait mettre son kernel.h dans TIGCCLIB, on le refuserait. Ça utilise des hacks, c'est incompatible avec les anciens kernels, et il propose des fonctions pour le mode kernel sans proposer d'équivalent _nostub (alors que toute fonction de TIGCCLIB doit être disponible dans les 2 modes).

Kevin Kofler
a écrit : c'est incompatible avec les anciens kernels

QUELS anciens kernels?
Franchement il n'y a plus d'anciens kernels, ils sont au moins autant dépassés que le format kernel l'est pour toi...

Pour moi, les seuls "anciens kernels" qui existent sont les versions antérieures de preOS... Bon d'accord on peut appeler cela un "monopole" mais on a l'habitude...

Link a écrit :
QUELS anciens kernels?

DoorsOS, TeOS, Universal OS, ...

Pour moi, les seuls "anciens kernels" qui existent sont les versions antérieures de preOS...

Mais les RAM_CALLs comme Ptr2Hd sont incompatibles même avec des versions suffisamment anciennes de PreOs!

Je me doutais de la reponse.

Kevin Kofler a écrit :
DoorsOS, TeOS, Universal OS, ...

Encouragerais-tu encore vraiment quelqu'un qui veut faire tourner des programmes pour kernel à utiliser ça ?

Non, mais ça existe quand-même.
C'est comme pour AMS 1: je ne le conseille à personne, mais je rends quand-même mes programmes compatibles avec AMS 1 dans la mesure du possible.

si les vieux kernels st encore utilisés (DoorOS particulièrement) c'est surtout à cause de cette catégorie à la con sur ticalc ... sans ça tout le monde utiliserait des versions de PreOS à jour