Oui ça j'avais compris c'est pour cela que là ou je dois écraser par la suite je met des TAG_unitile en nombre suffisant pour écrire dessus par la suite.
Mais si je veux faire un memcopy de l'estack entre 2 pointeurs je fait comment ?
parce que si on peut convertir les ESI en pointeur sur void * je supose alor je pourrait implémenter l'insertion ?
existe t-il une fonction pour transformer les ESI en pointeur ?
En français s'il te plait K.K. ! en Français !
Déjà qu'il faut se taper le Manuel en anglais de TIGCC, va pas mettre de l'anglais dans tes phrases.
C'est déjà assez compliqué comme ça !
non-overlapping == qui ne se recouvre(nt) pas
Le cas "non-overlapping", c'est le cas dans lequel la zone source et la zone destination sont des ensembles distincts.
je te signale que je débute en C, alors du calme. je fait ce que je peux et s'il m'arrive de me tromper en utilisant des terme c'est juste parceque je ne peux pas lire toute la documentation en même tant. là je travail sur la pile pas sur la mémoire.
Tu vas finir par empêcher quelqu'un d'emettre des idées à la fin !
c'était une suggestion de débutant en C et crois moi ça va pas durer bien longtemps !
Donc si je comprend bien , je peux redimensionner la pile avec realloc et ensuite un petit coup de memmove pour faire de la place à l'endroit voulu , et voici l'insertion dans le ESTACK.
Bon je ne vais pas redimensionner l'estack si ien sur tu peux me dire :
- Si elle a occupe en mémoire une place fixe dont on connait les adresse des pointeurs debut fin pour au moins augmenter la pile sans écraser un autre espace reservé. Mais je doute que ce soit ainsi. La pile se crée et se détruit par appel de chaque prog je pense.
Je vais voir le source dont tu parle en cerchant dans google.
La pile d'expressions est un handle locké toujours alloué, elle n'est pratiquement jamais redimensionnée. C'est elle qui prend une grande partie de la mémoire "System".
ok donc comment je fait pour connaître le maxî de pile j'ajoute sa taille au pointeur pour le dire grossièrement. comme ça je ne pourrait pas écrire en dehors.
Mais à t'on avis est-ce plus rapide de manipuler et déplacer des arguments directement sur la pile que de les sauvegarder dans des tableau pour ensuite les recopier ? car après tout cela revient à des copies de données entre de pointeurs. Et si cela se trouve je vais peut-être perdre du temps à manipuler la pile en créant l'insertion qui à chaque fois devra deplacer des blocs de mémoire.
C'est quoi ton avis K.K.?
La taille maximum, c'est 65520 octets normalement.
Et je ne sais pas ce qui est plus rapide.
Ok ! une autre question.
Vu la méthode proposée pour efface l'estack dans l'exemple 'ADD 2 number' de TIGCC, je me pose des questions :
-tu déplace le top_estack après les arguments de la fonction appellante et on s'arrête au premier END_TAG , ( c'et une méthode pour des argument simple.
je suppose que dans l'absolu, on doive deplacer le top_estack au bottom_estack.)
- ça efface pas vraiement : donc en déplaçat ainsi le top_estack on arrivera à la fin de la zone mémoire allouée à l'estack forcément.
Que se passera t'il alors : je suppose un Garbage Memory non !
Non, en déplaçant top_estack de cette manière, les arguments se trouvent pour AMS "en dehors" de la pile d'expressions (plus précisément: en dehors de la partie utilisée de la pile d'expressions; le handle, lui, ne bouge pas) et la prochaine écriture les écrasera.
K.K.> oui mais j'ai pas de reponse pur la meilleur façon d'effacer le top estack , surtout lorsqu'on utilse des arguments complexes qui comporte eux même des END_TAG. du coup l'effacement va s'arrêter uau 1er END_TAG trouvé.
C'est plus sur d'aller jusqu'à botom_estack qui je suppose pointe sur le END_TAG de la fonction qui à passée des arguments sur la pile non !
comme ça on est toujours sur de ne rien laisser trainer
Non, tu ne peux pas effacer jusqu'à bottom_estack. Il peut y avoir aussi d'autres trucs sur la pile d'expressions:
* historiques
* autres appels dans la même ligne
...
Ah pardon , autant pour moi je me suis laissé allez à délirer alor que j'utilise cette astuce pour passer les arguments de mon prog 'mkarg' à une fonction/programme en les laissant trainer sur la pile.
En claire y a-t-il un moyen de savoir où fini l'appel d'une fonction ? (un TAG par exemple)
Ou mieux encore combien d'arguments sont passées à une fonction ; en supposant bien sur que la fonction appelée est imbriquée dans plusieurs appels.
Il ne me reste alors que la solution de passer un Caractère pour indique la fin de ma fonction (genre un TAG)
PpHd Le 17/09/2004 à 13:09 >En claire y a-t-il un moyen de savoir où fini l'appel d'une fonction ? (un TAG par exemple)
ESI *p;
while (*p != END_TAG)
p = next_expression_index (p);
>Ou mieux encore combien d'arguments sont passées à une fonction ; en supposant bien sur que la fonction appelée est imbriquée dans plusieurs appels.
GetArgCount ?
Oui mais en passant par exemple une liste en argument d'une fonction ton code ne risque pas de s'arrêter à celui-ci plutôt qu'à celui de la fonction ?
GetArgCount : dans un apel comme f(g(mkarg(v(x,c),y,n),z),a,b) ça ramène quoi ? (mkarg étant la fonction C sachant toute l'expression est sur la pile ?
Et la lumière fût ! Il vit de nouveau claire.
Merci K.K.
Que se passe t-il si on ajoute une variable à la pile quand elle est pleine ? (Error je suppose)
On fait comment pour regler ça ?
KK t'a dit que la pile fait environ 55ko.
Je suppose que top_estack a une valeur par défaut qui est restoré avant chaque appel.
faut donc que j'ajoute à ça la taille de la pile qui est constante pour savoir à partir d'où je ne peux plus écrire.
PpHd Le 04/10/2004 à 11:55 >On fait comment pour regler ça ?
On recupere les exceptions.
>Je suppose que top_estack a une valeur par défaut qui est restoré avant chaque appel.
Non
>faut donc que j'ajoute à ça la taille de la pile qui est constante pour savoir à partir d'où je ne peux plus écrire.
Que ? Areuh ? La taille de la pile est pas constante mais dynamique.
Tu peux pas travailler avec la pile estack proprement ? Ca sera plus simple, plus sur, et surement plus efficace.
Tu crois vraiment que c'est plus rapide de recuperer les arguments dans une structure, pour les réutiliser par la suite quand je peux les laisser dans la pile et les récupérer à volonté !
Surtout quand ces arguments ne serviront qu' une fois dans la majeure partie des cas !
Le problème c'est que je fait une Lib qui depose des résultats de tout type sur la pile ; qu'une autre fonction peut récupérer lorsqu'elle n'a pas le nombre d'arguments qu'il faut.
Je veux pas créer de structures pour sauver temporairement les résultats.
Du moins pour le moment ça me semble prendre de la place alors que l'estack est déjà alloué et donc disponible.
Bien sure je changerai d'avis s'il c'est plus rapide de faire autrement mais c'est pas sure !
Je sais que la pile est dynamique mais elle ne peut excéder une limite de taille ; de plus l'ESTACK est compris dans la Mémoire SYSTEM selon K.K.
Et surement je pense que top_estack en dehors de tout appel est à sa valeur d'initialisation.
Mais je trouverai bien la valeur maxi que peut prendre top_estack.
Non ça marche impeccable avec ce system ; j'ai tester : la recup des arguments laissé sur la pile par d'autres fonc est impécable et je nettoie correctement l'estack avant de sortir.
J'ai effectuer les 1er test Hier soir et là j'implémente les fonctions standar.
Je comprends pas pourquoi tu dit que c'est plus rapide ta méthode. comparons :
soit la fonction de ma lib "text",STR_LIST,X_LIST,Y_LIST,FONT pour afficher du texte
Moi -> Je lis dans l'estack , et j'affiche au fur et à mésure
PpHd -> tu lis dans l'estack ,tu sauvegardes dans une structure, ensuite tu affiches
PpHd Le 04/10/2004 à 16:03 Le parcourt d'expression dans l'EStack est couteux. Evidemment si tu lis parcourts l'ensemble de tes arguments une seule fois, c'est pas plus couteux. Mais vu tes remarques, je me demande toujours ce que tu fais avec l'EStack pour necessiter tant de hacks.
Vu que la Lib doit supporter
-les Boucles
-les indirections internes sur les variables
-modification des variables et eventuellement des compteurs sur lesquels porteront les boucles
Si je sauvegardais les arguments de la lib ça me ralentirai surement dans les boucles.
Mais je vais voir si dans certains cas une sauvegarde par allocation dynamique temporaire ne srait pas utile
en cas d'appels successif sans modification interne des arguments.
M'enfin ça reste à voir.
Mais c'est vraiment gore!
)
