Exécution de programmes - Page 1

Voila, j'ai un petit probleme : pour exécuter un programme, j'utilises ça :
char execASM (char *str)
{
char *src, name[20];
unsigned short len;
HANDLE handle;
SYM_ENTRY *SymPtr;
if (utilise (str))
{
return 1;
}
name[0] = 0;
strcpy (name+1, str);
handle = DerefSym (EM_twinSymFromExtMem (name+1+strlen (str), HS_NULL))->handle;
if (HeapGetLock (handle))
{
src = HeapDeref (handle);
handle = 0;
}
else
src = HLock (handle);
len = *(unsigned short*)(src) + 2;
EX_patch (src + 0x40002, src + len + 0x3FFFF);
// Appel avec support du RETURN_VALUE
TRY
asm volatile("movem.l %d0-%d7/%a0-%a6,-(%sp)");
ASM_fastcall (src + 0x40002);// ASM_fastcall parce qu'il faut des nop's
asm volatile ("nop; nop; nop; nop;"); // il les faudra si le prog appelé a un "#define RETURN_VALUE"
asm volatile("movem.l (%sp)+,%d0-%d7/%a0-%a6");
ONERR
ST_showHelp ("Erreur");
ENDTRY
if (handle)
HeapUnlock (handle);
if ((SymPtr = SymFindPtr (name+1+strlen (str), 0))->flags.bits.twin)
SymDelTwin (SymPtr);
return 0;
}

Or, il semblerait que sur cetaines configurations, il apparaisse une "error memory". De plus, l'erreur se produit de préférence a l'écution d'un prog avec arguments, empilés sur la pile comme ça :

char execInt (char *str, char *interpr)
{

unsigned char *src, name[20], r = 0;
unsigned short len;
ESI top_estack_backup = top_estack;
SYM_ENTRY *SymPtr;
name[0] = 0;
strcpy (name+1, str);
push_END_TAG();
push_expr_quantum (name+1+strlen (str), STR_TAG);
strcpy (name+1, interpr);
SymPtr = SymFindPtr (name+1+strlen (interpr), 0);
if (!SymPtr)
return 5;
r = execASM (interpr);
top_estack = top_estack_backup;
return r;
}

Donc je voudrais savoir si cette méthode est valide...
Petite précision : j'utilise les Twins plutot qu'un HeapAllocHigh car sinon, l'éxécution d'un prog comme Tictex plante plus ou moins, et en plus c'est sensé etre la méthode de TI...

Ça m'a l'air correct. Je pense que le problème est que ton shell consomme tout simplement trop de mémoire.

ce qui est bizarre, c'est que ça marchait dans la version 1.06, par contre dans la version 1.09, ça plante chez un utilisateur de 89 HW2 ROM 2.05. Par contre, chez moi (89 HW1 2.05), ça marche très bien.
Et au niveau mémoire, j'en consomme pas plus a la 1.09 qu'a la 1.06 !
En gros, pour ces routines, la seule chose que j'ai changé, c'est la version de TIGCC...

A quand le compilo linké statiquement avec les sources du programme?

À toi de le faire, c'est toi qui fais un compilateur on-calc.

On-calc y a pas vraiment la place de copier 100 ko à chaque prog Et puis heureusement que certaines personnes se soucient de la backwards-compatibility

Nous aussi, on se soucie de la compatibilité antérieure. S'il identifie un problème concret lié à la nouvelle version de TIGCC, qu'il nous la reporte. Ici, je pense que le problème est tout simplement que son shell consomme trop de mémoire.

Guilc, même si le shell a grossi d'un seul octet, ça suffit pour expliquer qu'une erreur Memory apparaît là où il n'y en avait pas avant. Et la raison pour laquelle ça apparaît sur une calculatrice et pas sur une autre est probablement une différence dans la taille de mémoire consommée par des TSRs.

Heu excuse-moi mais y a pas mal de fois où pour passer à la version suivante de TI-GCC j'ai été obligé de porter mes progs - enfin c pas trop grave, juste pour dire que si un compilo en a besoin, c certainement pas GTC

Ce genre de trucs se reporte comme un bogue. Ce n'est pas normal.

Et depuis la version 0.93, je vérifie personnellement qu'il n'y a pas de problèmes de compatibilité (en compilant TI-Chess - Thomas s'était lui aussi plaint qu'il a été obligé à chaque fois de changer 2-3 trucs dans TI-Chess quand il a changé de version de TIGCC, donc je vérifie maintenant pour que cela ne se produise plus). La 0.94 devrait accepter tout ce qui était accepté par la 0.93, à condition de ne pas utiliser -mregparm ou USE_FLINE_ROM_CALLS (si on utilise ça, un portage est nécessaire dans certains cas).

Kevin Kofler a écrit :
Guilc, même si le shell a grossi d'un seul octet, ça suffit pour expliquer qu'une erreur Memory apparaît là où il n'y en avait pas avant. Et la raison pour laquelle ça apparaît sur une calculatrice et pas sur une autre est probablement une différence dans la taille de mémoire consommée par des TSRs.

Ca me semble difficile que ce soit un probleme de mémoire insuffisante, vu que la RAM libre est de 153978 octets pendant l'éxécution de TiEX, ce qui signifie que le programme a exécuter bénéficie de toute cette quantité de RAM...

Quel était le programme exécuté? Il y a quand-même 42 KO sur les 192 KO qui sont consommés, c'est trop pour pas mal de programmes. À titre de comparaison, TICTEX consomme 7 KO seulement lors de l'exécution d'un programme.

le prog exécuté, c'est TxtRider (pas un modele de stabilité non plus). En fait, c'est pour lancer le viewer sur un texte.
Et en fait, TiEX prend pas 42ko, mais 30 (celui chez qui ça buggue doit avoir des trucs pas archivés). en gros, ça fait 20ko de prog + 10ko de sauvegarde d'écran, sprites des fontes , etc... Et je suis pas capable de faire un prog qui libere la memoire de sa partie GUI... (du moins sans fork )

Bon, bah, dans ce cas-là, je pense que c'est un bogue de TxtRider tout simplement. Et il n'a pas besoin de tant de mémoire normalement, mais c'est un programme spécialiste des bogues bizarres...

Ouaip, c'est bien Txtrider le probleme : l'utilisateur chez qui ça plantait a mis hibtext, et ça marche...