top_estack() - Page 2

Euh, si tu penses aux bra.s etc., c'est juste une autre manière d'écrire bra.b. Si effectivement tu pensais à l'extension du fichier, alors, comme l'a dit nEUrOne, c'est l'extension utilisée pour l'assembleur GNU.

Non, c'est bien le bra.b

Ah oui, et une petite question. Quand j'execute un programme assembleur f(2,3), la represention de l'estack est bien la suivante?

...$2,$1,$1f, $3,$1,$1f ...

y a t il un autre tag séparateur entre les octes $1f et $3 ?

Pour savoir vraiment, lance un programme tel que tthdex et dumpe l'EStack. L'EStack est marquée, même depuis des versions préhistoriques de tthdex. C'est un handle de 16384 octets, de numéro bas.

L'estack fait office de pile pointé par sp?

Pardon ? Je ne suis pas sûr d'avoir bien compris, là ?

Je voulait juste savoir si l'estack c'était la fameuse zone mémoire de 16ko ou ont sauvegarde des données temporairement en empilant sur a7?

Non. TIOS utilise l'estack pour faire les calculs. La pile (a7) s'utilise pour stocker des données temporaire et pour les passer aux fonctions de la TIOS (et les fonctions qu'on crée, si on ne passe pas -mregparm à GCC).

Oui, donc j'avais bien compris ce que tu voulais dire...
Joel a répondu.
L'octet le plus bas de l'EStack est, pour autant qu'il me semble, bottom_estack. L'octet le plus haut de la pile user est 0x41FF, celui de la pile superviseur 0x4BFF.

>joelt49 : tiens, on te vois pas souvent ici

ok merci, je vais eesayer ttdhex

Tails a écrit :
Ah oui, et une petite question. Quand j'execute un programme assembleur f(2,3), la represention de l'estack est bien la suivante?

...$2,$1,$1f, $3,$1,$1f ...

Non, c'est ...,$e5,$3,$1,$1f,$2,$1,$1f,...

y a t il un autre tag séparateur entre les octes $1f et [$2] ?

Non, il n'y a pas de séparateur entre les 2 arguments. Utilise next_expression_index pour trouver la fin d'un argument.

J'ai dit une bêtise: bottom_estack n'est pas l'octet le plus bas de la EStack.

tthdex 2.70 ou 2.80 est très loin d'être parfait (il y a des bugs graves), mais si tu t'en sers juste pour dumper la EStack, il est très improbable que tu tombes dessus... Sinon, je t'enverrais bien des binaries, sauf qu'actuellement, tthdex est inutilisable (modifications lourdes)...

XDanger>Oui c'est vrai, j'ai vu que passer ttdhex avec l'estack, la rendait indisponible dans le navigateur, qui est merveilleux. Il est très complet : moi qui croyait qu'il n'y avait qu'une simple liste de HANDLE, il y a aussi un superbe navigateur accompagné d'un lecteur héxadécimal! Un grand bravo aux auteurs

Kevin Kofler> Oups! J'ai oublié que les arguments sont empilés à l'envers sur l'estack. Sinon, ca m'a pas empêché d'avoir écrit une fonction GetStrnArg, qui au bout du compte renvoie bien un pointeur sur le tag de l'argument suivant.(Mais moi j'ai préféré que l'on passe aussi un argument buffer, pour ne pas se contenter de renvoyer une constante chaine, susceptible d'etre détruite). Par contre, c'est le bug que je connais pour l'instant avec GetIntArg. Donc je rajouterais ces deux fonctions dans ma patchlib (qui est loin de présenté du code très optimisé, mais au moins il permet de ravir les impatients de mon genre) plus tard que prévu.

Merci à toi de me faire des compliments à propos de tthdex. Je n'en suis certes pas l'auteur original (c'est évidemment Thomas Nussbaumer), mais tthdex n'a plus rien à voir avec ce qu'il était quand je l'ai pris en main. tthdex 2.80 est assez loin de la version interne, qui ne marche pas actuellement (nouveau GUI, nombreuses nouveautés, plus rapide). Et la todo list est énorme...

Tails
a écrit : Kevin Kofler> Oups! J'ai oublié que les arguments sont empilés à l'envers sur l'estack. Sinon, ca m'a pas empêché d'avoir écrit une fonction GetStrnArg, qui au bout du compte renvoie bien un pointeur sur le tag de l'argument suivant.

Dans ce cas particulier, le format est simple. Maintenant, essaye de faire ça avec une expression formelle compliquée, et tu verras à quel point next_expression_index est pratique.

(Mais moi j'ai préféré que l'on passe aussi un argument buffer, pour ne pas se contenter de renvoyer une constante chaine, susceptible d'etre détruite).

Le buffer est totalement inutile. Les arguments restent sur la pile d'expressions tant qu'on ne les supprime pas explicitement. En revanche, avec ton buffer, tu introduis un risque de plantage par débordement. Donc c'est mieux sans.

ouais c'est vrai, pas besoin de se casser la tete avec des buffers