FTL Parser 2004 - Page 7

Raphaël
: Ah oui et puis je voulais te demander un truc Kevin : comment peut-on faire en C pour exécuter un programme avec un paramètre : comme dans en BASIC où l'on met les paramètres entre paranthèse. Pour exécuter un programme depuis un programme C je sais faire mais je ne sais pas comment lui passer le paramètre.

Tu les passes sur la pile d'expressions. push_END_TAG();, puis un push de chaque paramètre en partant du dernier.

Ok merci bien.

Tu les passes sur la pile d'expressions. push_END_TAG();, puis un push de chaque paramètre en partant du dernier.

J'ai qu'un seul arguments à passer. Par contre je n'ai aps compris comment passer le paramètre : je fais push_END_TAG et puis après ? ... c'est quoi le push ?
J'ai essayer avec cette fonction :

void Open_FTL_File(const char *fname)
{
HANDLE h;
push_END_TAG();
push_ANSI_string("maths"); // paramètre FTL Parser : nom du fichier TEXT
push_parse_text ("ftlparse()");
h = HS_popEStack ();
TRY
NG_execute (h, FALSE);
FINALLY
HeapFree (h);
ENDFINAL
}

mais évidement ça ne marche pas : ça ne doit pas être push_ANSI_string() qu'il faut utiliser pour passer le paramètre.
Sinon sur PedRom on peut bien lancer un programme avec le code de la FAQ de TIGCC que j'ai emprunté pour faire la fonction ci-dessus mais en quittant e programme il y a une erreur d'adresse mémoire. Donc pour l'instant on ne pourra pas lancer FTL Parser depuis un programme C... à moins que quelq'un à une autre méthode ?

push_ANSI_string est bon.
Le problème est que tu utilises la méthode push_parse_text, alors que ce que j'ai donné est pour l'appel direct à la http://tigcc.ticalc.org/doc/faq.html#49. (Ta méthode présuppose que h220xTSR ou HW2Patch est présent sur HW2 AMS 2, sinon ça plante, donc je ne la conseille pas.)
Avec push_parse_text, il faut passer les paramètres entre les parenthèses comme en BASIC.

Euh oui, alors il faut que je fasse quoi ?

Ben, push_parse_text ("ftlparse(\"maths\")"); si tu veux utiliser cette méthode.

Mais la méthode propre, c'est:
#define EXECUTE_IN_GHOST_SPACE
au début de ton programme, et:

  char *fptr, *cptr;
  unsigned short plen;
  SYM_ENTRY *SymPtr = DerefSym (SymFind (SYMSTR ("example")));
  HANDLE h;
  if (!SymPtr) fatal ("Program not found");
  h = SymPtr->handle;
  if (HeapGetLock (h))
    {
      cptr = fptr = HeapDeref (h);
      h = 0;
    }
  else
    {
      cptr = fptr = HLock (h);
    }
  plen = *(short*)(cptr) + 3;
  if (SymPtr->flags.bits.archived)
    {
      if (!(cptr = malloc (plen)))
        {
          if (h) HeapUnlock (h);
          fatal ("Out of memory");
        }
      memcpy (cptr, fptr, plen);
    }
  EX_patch (cptr + 0x40002, cptr + plen + 0x3FFFE);
  push_END_TAG(); 
  push_ANSI_string("maths"); // paramètre FTL Parser : nom du fichier TEXT 
  ASM_call (cptr + 0x40002);
  if (h) HeapUnlock (h);
  if (cptr != fptr) free (cptr);

Ouais... je sais pas... on est obligé de le mettre le #define EXECUTE_IN_GHOST_SPACE ? La deuxième solution va bouffé le double de mémoire au programme de l'utilisateur par rapport à la première.

Raphaël
: Ouais... je sais pas... on est obligé de le mettre le #define EXECUTE_IN_GHOST_SPACE ?

Oui!

La deuxième solution va bouffé le double de mémoire au programme de l'utilisateur par rapport à la première.

Mais c'est la seule qui ne plante pas!

Ouais, ok. Sous PedRom elle ne passe pas... enfin si au début elle plante et puis après ça marche mais ça n'ouvre pas le programme avec le bon fichier.
Et puis je ne comprend toujours pas pourquoi les dernière beta de TIGCC bouffe autant de place : sur une ancienne version de TIGCC le programme fait 281 octets et 421 sur avec la dernière beta rien qu'avec la deuxième solution !
En mettant :
#undef __need_in_use_bit
#define __need_in_use_bit ((void)0)
je retombe à 283 quand même... j'ai toujours pas compris à quoi ça servait ce truc qui a été implémenté... avant ça ne genait pas le fonctionnement des programmes quand ça n'y était pas ?

Raphaël
: avant ça ne genait pas le fonctionnement des programmes quand ça n'y était pas ?

Si, le programme peut planter sans ça (ainsi qu'avec ton hack)!!!
Comme déjà dit, ce hack ne convient que si tu es absolument sûr que ton programme n'utilise pas le event loop. Vu ton niveau, ça ne sera jamais ton cas, donc n'utilise pas ce hack!

Il faudra que tu comprennes que le fait d'avoir un programme qui ne plante pas est nettement plus important que 140 misérables octets!

Cela dit, je sais que ce flag est mis pour des fonctions qui n'en ont probablement pas besoin, je vais règler ce problème. Mais il faut que je vérifie fonction par fonction. Je préfère de loin des programmes qui prennent 140 octets inutilement à des programmes qui plantent parce qu'il n'y a pas ces 140 octets.

Il faudra que tu comprennes que le fait d'avoir un programme qui ne plante pas est nettement plus important que 140 misérables octets!

Ah ok je ne savais pas... bon bah je vais vite enlever le "hack" en espérant qu'il n'y ait plus de crash du tout !


Et puis je voudrais aussi optimiser cette fonction qui permet de copier une partie d'une chaîne, déterminé par les coordonnées begin et end, dans une autre :
__attribute__((regparm))void sub_str(unsigned long begin, unsigned long end, unsigned char *str, unsigned char *str_dest)
{
unsigned long i = end-begin+1;
str += begin;
while(--i)
{
*str_dest++ = *str++;
}
*str_dest = 0;

}

Alors tout d'abord j'ai fait ça :
__attribute__((regparm))void sub_str(unsigned long begin, unsigned long end, unsigned char *str, unsigned char *str_dest)
{
unsigned long i = end-begin+1;
str += begin;
while(i>4)
{
*str_dest++ = *str++;
*str_dest++ = *str++;
*str_dest++ = *str++;
*str_dest++ = *str++;
i=i-4;
}
while(--i)
{
*str_dest++ = *str++;
}
*str_dest = 0;

}

Et ça marche plutôt bien sauf pour les chaîne inférieur à 3 caractère évidement ou ça met plus de temps. J'utilise cette fonction sur des chaînes comprises entre 3 et 10 à 15 caractère mais en moyenne ça doit tourner autour de 4-5 sauf exception.

Ensuite j'ai voulu utiliser des long pour copier 4 octets en même temps mais là ça ne marche plus et je ne comprend pas trop pourquoi :
__attribute__((regparm))void sub_str(unsigned long begin, unsigned long end, unsigned char *str, unsigned char *str_dest)
{
unsigned long i = end-begin+1;
unsigned long *dest = (unsigned long*)str_dest;
unsigned long *src = (unsigned long*)str;
str += begin;
while(i>4)
{

*dest++ = *src++;
i=i-4;
}
while(--i)
{
*str_dest++ = *str++;
}
*str_dest = 0;

}

Ca vient de quoi ?

Adresse impaire?

Et il faudrait que je fasse quoi pour y remédier ?

Que tu réfléchisses peut-être...
Le 68000 ne te permet pas de manipuler autre chose que des octets aux adresses impaires, donc soit tu copies octet par octet, soit tu copies juste un octet pour que l'adresse de la prochaine donnée soit paire puis tu copies des long, soit tu te débrouilles pour que tes adresses soient toujours paires, ...

Que tu réfléchisses peut-être...

Oui il faut dire que je n'ai pas beaucoup de notion sur le 68k vu que je programme qu'en C.

soit tu copies juste un octet pour que l'adresse de la prochaine donnée soit paire puis tu copies des long, soit tu te débrouilles pour que tes adresses soient toujours paires,

Bon bah merci je vais me débrouiller merci.

Non. Relis bien sa phrase.

J'ai fait des tests avec PedRom et je me suis aperçu que le programme était presque deux fois plus lent sans que j'arrive à trouver pourquoi.... il y a déjà eu le même pb avec d'autres programmes ?
Et sinon j'ai vu que le mode idle ralentissait pas mal le programme aussi alors je voulais savoir si ça valait la peine de faire comme je fait actuellement c'est à dire plusieurs pokeIO(0x600005,0b10111) à la suite dans une boucle comme celle-ci par exemple ? :
do
{
gray_idle(); // réduit la consommation des piles

}while(!GX_rowread(0));


void gray_idle(void)
{
pokeIO(0x600005,0b10111);
pokeIO(0x600005,0b10111);
pokeIO(0x600005,0b10111);
pokeIO(0x600005,0b10111);
}

Plusieurs PokeIO à la suite ne servent pas à grand chose...

Sinon, tu utilises memcpy, memset, ... ?

D'accord, merci. L'interruption la plus rapide fait 90 hz d'après Kevin vu que c'est les niveaux de gris et la boucle est carrément bien plus rapide.
En plus j'ai mnt deux mode idle : un pour quand le programme à besoin du timer et un pour quand il n'en a pas besoin qui est cette boucle là justement afin que ce soit plus efficace.

Sinon, tu utilises memcpy, memset, ... ?

Pour afficher l'écran j'utilise memcpy parce-que sur la ti 89 on peut copier 3000 au lieu de 3840.

Et puis cette routine que j'ai programmé (elle ne doit pas être super efficace mais il me semble qu'elle est plus rapide que memset d'après un bench. En même tps je ne voulais pas qu'elle prenne trop de place :

void Clear_Gray_Virtual_Screen(void)
{

//memset(Light_Buffer,0,size_screen_buffer);
//memset(Dark_Buffer,0,size_screen_buffer);

register unsigned long *buffer asm("a1") = Light_Buffer;
register unsigned long *buffer_2 asm("a0") = Dark_Buffer;
short lenght = size_screen_buffer;
register long value asm("d1")=0;
while(lenght)
{
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
*(buffer_2++)=value;
lenght-=64;
}


}
Là je n'ai pas eu à me soucier des adresse paires... c'est pour ça que je n'ai pas compris pourquoi ma routine pour extraire une chaîne ne fonctionne pas...mais bon du coup j'ai abandonner de toute façon même si je l'optimise à fond ça ne va pas changer grand chose.
Pourquoi cette question ?

memcpy est lent sur PedRom.

Ta routine pour effacer l'écran virtuel, tu devrais la coder en ASM.

memcpy est lent sur PedRom.

PpHd l'a pas corrigé? (cf je sais plus quel topic)

Ta routine pour effacer l'écran virtuel, tu devrais la coder en ASM.

En fait j'ai regardé le code produit par TIGCC en asm pour pouvoir la coder. Et puis des routines en asm pour effacer les buffer c'est pas ce qui manque... d'ailleurs j'avais utilisé celle de extgraph mais pour la Ti89 ça sert à rien d'avoir des buffer de 3840 !
Et puis en asm avec movem.l ça prend un paquet de place par rapport à la mienne.

PpHd l'a pas corrigé? (cf je sais plus quel topic)

Bah pas dans la version 0.80 en tout cas.

Oui, mais ça commence à faire un bout de temps que la 0.80 est sortie...

Pollux
:

Raphaël
:

Ta routine pour effacer l'écran virtuel, tu devrais la coder en ASM.

En fait j'ai regardé le code produit par TIGCC en asm pour pouvoir la coder. Et puis des routines en asm pour effacer les buffer c'est pas ce qui manque... d'ailleurs j'avais utilisé celle de extgraph mais pour la Ti89 ça sert à rien d'avoir des buffer de 3840 !
Et puis en asm avec movem.l ça prend un paquet de place par rapport à la mienne.

PpHd l'a pas corrigé? (cf je sais plus quel topic)

Bah pas dans la version 0.80 en tout cas.

Oui, mais ça commence à faire un bout de temps que la 0.80 est sortie...

il ne fait pas oublier que la 0.80 est une beta publique et que PedroM est sous une licence OpenSource, rien n'empeche quiquonque de retrousser ces manches et d'aider PpHd si on découvre/resou des bugs, il en sera surement meme tres content

Raphaël
: D'accord, merci. L'interruption la plus rapide fait 90 hz d'après Kevin vu que c'est les niveaux de gris et la boucle est carrément bien plus rapide.

Faux, elle fait >200 Hz. Le handler des niveaux de gris ne les utilise pas toutes, parce que le LCD ne va qu'à 90 Hz.