arguments sur la pile - Page 3

>Bon Heureusement que je nettoie la pile en m'arrêtant au debut de l'appel de la Lib.
Ben c'est ce qu'on doit faire...

J'ai pas dit que j'utilisais pas les fonctions d'accès du TIOS : j'ai dit que je laissais les valeurs sucessives retornées par les fonctions internes de la librairie sur la pile; donc j'utise 'push_'

Je fais juste que recuperer les valeurs une par une pour completer les arguments d'une fonction à laquelle il manque des arguments.
J'ai fais le choix de laisser progressivement les résultats sur la pile !
Pour le moment je n'ai pas encore décider si je ne me limitais qu'à traiter les types STR,NUM et les structure Tibasic LIST,MAT,DAT.

En effet je me demandais s'il serait intéressant de traiter les types de décimaux pour une librairie du moins juste pour faire 'sprintf' (si c'est plus rapide que 'string' en basic ça vaut peut-être le coup !).

PpHd ->
T'as raison il y a des cas ou on peut avoir besoin plusieurs fois des données qu'on a posé dans l'estack !

j'ai décider de mettre à disposition 5 pointeurs sur tableau structure pour recuperer les arguments(Alloc dynamique bien sure).

je vais donc rediriger ma fonction 'push' dans un de ces buffer tabeau de structure en changeant la syntaxe comme suit :
"push","#Buffer_num_0_à_5",arg1,arg2,arg2,.......

avec
"#0" -> ESTACK
"#1" à "#5" -> Tableau de struture par alloc dynamique


Le problème c'est que j'ai beau creusé je ne trouve pas beaucoup de cas de figure où ça pourrait servir.
Je ne vois que le cas suivant :
Il s'agit d'un appel dans une boucle pour
affichager du texte ou des dessins avec les routines graphiques à partir d'une LIST/MATRIX/DATA avec prise en compte du scrolling à l'intérieur d'une fenêtre.

Alors si quelqu'un peut élargir mon horizon , je suis prêt à prévoir plus de 5 pointeurs

J'ai secouer la doc dans tous les sens et pas moyen de trouver une fonction qui fait le remontée l'ESTACK dans le sens opposé à celui de next_expression_index().
En fait j'ai implémenté des déplacements en Avant et en Arrière dans l'ESTACK.

pour l'avant c'est à coup de 'SkipArg(argptr)' ; quoi de plus simple !

c'est autre chose que de redescendre le long de la pile vers le top_estack !

je suppose que les vrais languages indexent la pile pour un accès rapide et qu'ils doivent remplacer les structures conditionnelles et de contrôles par des pointeurs sur pour effectuer les branchement lors de la tokénéisation.

Mais n'y-t-il pas un moyen plus simple de redescendre le long de la pile sans faire (argprt++)!=SEARCH_TAG au risque de tomber sur ce SEARCH_TAG en parcourant le contenu d'un INT ou d'un STR ?

Bien sur je peux ignorer ce TAG si je suis à l'intérieur des octets d'une variable.

C'est juste pour savoir. j'ai déjà implémenter tout cela pour faire des boucles dans ma Lib.
ça marche très bien : 2 à 3 fois plus rapide qu'en basic pure.

Là je fait quelques optimisations dans le code.

>J'ai secouer la doc dans tous les sens et pas moyen de trouver une fonction qui fait le remontée l'ESTACK dans le sens opposé à celui de next_expression_index().
Normal. Ce n'est pas possible.

Deja que next_expression_index est lent, je veux pas savoir a quelle vitesse ca va aller.

-> Merci K.K.
Mais ça va être long de partir depuis le top estack ! vu que je ne gère que 4 TAG je vais m'arranger avec pour aller plus vite !

PpHd ->
A bon! je savais pas !

Donc tu crois que si je déplace le pointeur manuellement dans l'estack sans utiliser next_expression_index je pourrai être plus rapide ?
t'as déjà essayer ?
Si ça vaut le coup en vitesse je suis prêt à m'essayer à ça !

c'est certainement possible de faire plus rapide en gérant juste les les Tag suivant je suppose :
- STR_TAG
- POSINT_TAG
- NEGINT_TAG
- LIST_TAG


si c'est le cas : je planche dessus ce soir .

Merci pour la possible suggestion PpHd (à confirmer bien sur, faut pas que je bosse pour rien !)

>Donc tu crois que si je déplace le pointeur manuellement dans l'estack sans utiliser next_expression_index je pourrai être plus rapide ?
Si tu as le courage de reimplanter tout next_expression_index, peut etre. Ou utilise une version plus rapide deja disponible de cette routine (Cf la routine de Samuel si mes souvenirs sont bons).

ppHd > s'il ne gère que 4 tags, ça devrait être faisable, nan ?

Rien n'empeche que l'utilisateur donne des tags incorrect. Il faudrait qu'il le gere. M'enfin pourquoi pas, c'est vrai.
S'il n'a que ces 4 tags.

En fait 5 INFINTY_TAG pour separer les appel de la Lib.
Tout les autres TAG entraineront un message "Bad Argument Type! "

je vais voir chez samuel, et aussi essayer de faire ce truc pour ce soir ! Merci les potes.
Actuellement au Bench je suis à 6 centème de seconde derrière VERTEL.

Donc si j'accélère l'accès à l'ESTACK, ça va être chaud !
En plus j'ai une gestion supplémentaire des MATRIX != LIST.
je ne me contente pas de sauter les LIST_TAG à l'intérieur d'une LISTE.
------------------------------
je suis aussi à la recherche d'une routine très rapide de conversion des INT en STRING.
Si quelqu'un avait ça en ASM et prêt à l'utilisation, dans le read-me ; pour le bonheur de Basic User.

Peut-être que je vais penser à EXTRAGRPH pour faire un petit truc pour accelerer l'affichage du Text et des graphiques.
En fait je veux supporter le Scrolling d'un Tableaux de PIC ou de TEXT avec quelques feature en interne dans la Lib; histoire de donner un sens à mes boucles.

>je suis aussi à la recherche d'une routine très rapide de conversion des INT en STRING.
Ca existe. Regarde aussi chez Samuel

Je suis chez samuel c'est bon pour Int2str
mais Fast next_expression_index je trouve pas.


A propos vu que j'y connait rien en ASM , je sais pas comment utilise ce code en C.
si qu'unlqu'un pouvait m'aider pour inclure ça dans comme une fonction dans mon projet et que je puisse l'utiliser en C ; je lui serai gré !

Il est dans Hail Expression Writer

Et regarde les licenses avant aussi.

Kevin Kofler :

ESI previous_expression_index(ESI e)
{
 ESI p=top_estack, q=NULL;
 for (;p!=e;q=p,p=next_expression_index(p));
 return q;
}

Parcours de la pile à l'envers en O(n²)

Ok je verai pour les licences.
Je vais de ce pas tester pour voir ce que ça donne comme différence.
Sinon ça va pas être aussi facile si je doit reimplémenter ça.
Je vais me taper la structure des entiers , pour les string c'est assez simple.
M'enfin ça me ferai un peu chier mais histoire d'augmenter la vitesse d'accès au éléments , ça vaut peut-être le coup !

Vu que les sources sont en ASM, je peux rien en tirer.

J'ai lu la doc sur la structure des nombres entiers et des string et maintenant ESTACK.h pour voir à quoi ça correspond dans la pile.

Histoire de me fixer les idées

finallement je vais essayer de faire les codes tout seul pour voir.
J'ai pas encore decider de rendre public les sources alors si je dois inclure le code de quelqu'un d'autre ça va faire compliqué.

Je commence sur notepad histoire de voir ce que ça va donner.

-> PpHd

j'espère que tu penses que GetIntArg et GetStrnArg sont suffisament rapide. je n'est pas du tout envie de me retaper ces codes. Mais si tu penses que c'est pas assez rapide alors ...
Parcequ'il faut dit que ça fait du beau boulot !

www.nyall.net je crois ?

ça n'apporte rien de refaire 'next_expression_index' en C.
ça ne supporte que quelques TAG avec un résultat navrant !
j'ai augmenté la taille de ma LIB pour ne rien gagné en vitesse.

là il faut que je vois avec Stearley Sinon Vive le ROM_CALL next_expression_index.

Pour aller avec j'ai aussi refait 'RemainingArgCnt'.
Comme je suis un peu nouveau en C; je vois pas comment faire mieux

Voici le deux sources :
//Remplace next_expression index ESI my_nei(ESI argptr) {      ESI ptr=argptr;      short a=0;      do {           switch (*ptr) {                case LIST_TAG:                     a++;                     ptr--;                     break;                case END_TAG:                     a--;                     ptr--;                     break;                case STR_TAG:                     ptr-=2;                     while (*ptr)                          ptr--;                     ptr--;                     break;                case POSINT_TAG:                case NEGINT_TAG:                     ptr-=(*(ptr-1)+2);                     break;                case INFINITY_TAG:                     ptr--;                     if(a) numerr=err_sep;                     break;                default:                     numerr=err_typ;                     break;           }      } while (numerr==err_non && a>0);      return(ptr); } //Remplace RemainingArgCnt unsigned short my_ArgCnt(ESI p) {      unsigned short n=0;      do n++; while(*(p=my_nei(p))!=END_TAG);      return(n); }

J'ai contacté S.Stearley qui m'a conseillé quelques optimisations pour next_expression_index.

Je vais aussi essayer de faire 'previous_expression_index'

Pour le moment je n'aperçois pas les gains en Vitesse tant espérés

quoique ça semble un peu plus rapide :
voici les codes revus :

//Remplace next_expression index
ESI my_nei(ESI ptr)
{
register ESI p=ptr;
register short t;
short a=0;

do {
if((t=*p)==LIST_TAG) { a++; p--; }
else if(t==END_TAG) { a--; p--; }
else if(t==STR_TAG) { p-=2; while (*p) p--; p--; }
else if(t==POSINT_TAG || t==NEGINT_TAG) p-=(*(p-1)+2);
else if(t==INFINITY_TAG) {p--; a=-2;}
else a=-2;
} while (a>0);
if(a==-2) numerr=(t==INFINITY_TAG?err_sep:err_typ);
return(p);
}

//Remplace RemainingArgCnt
unsigned short my_ArgCnt(ESI p)
{
unsigned short n=0;
do n++; while(*(p=my_nei(p))!=END_TAG);
return(n);
}

--------------------------------------------------------------------
Int2str : je vous informe que S.Stearley va en faire une fonction utilisable en C