Reprise du message précédent :


Fais un effort, regarde la definition du zjmp .. et relis ma question, tu devrais trouver la similitude

C'est la seule raison que je vois, sinon ils se sont goures sur l'exemple ..

Ok, j'ai compris, ce sont des index!


Heu... c'est quoi un index?

Il y a un quota sur l'impression chez vous ?

C'est peut-etre mieux si t'imprimes tout ca et que tu prennes un crayon

ouais nan mais je regarderais ca trankil, y a un autre projet a faire, en plus le week-end prochain on a un rush, génial!

Le 26 novembre 2004 - 13 h 23, Woofy a écrit : Le 26 novembre 2004 - 12 h 48, iraysyvalo a écrit : Le 26 novembre 2004 - 12 h 11, Woofy a écrit : Ben Big endian veut dire que les octets se lisent de gauche a droite, l'octet le plus faibe a gauche. Little endian c'est l'inverse : l'octet le plus faibe a droite. Dans les 2 cas, dans chaque octet, le bit de poids le plus faible est a droite comme d'habitude. Je sais .. mais sur ce document, aucun exemple ou transparait la Big Endian Et Big Endian sur combien d'octets ?? Heu... je sais pas, faut regarder les specifs de la machine virtuelle. Mais bon ca je pense que ce n'est pas important pour le compilateur.

Alors t'as avance ? t'as des reponses sur la big endian ?

Bah une achine big endian, c'est une machine qui a decide de faire chier son monde car elle lit tout a l'envers (octet de poids le plus fort a droite)
Si je met la chaine de charactere suivant "1234" dans la machine j'aurais en little endian : 1234
et en bigendian : 4321

Par contre, dans chaque octet, le bit de poids le plus faible est a droite, normal quoi. Quand au fat sur combien d'octets, ben 4, c'est une machine virtuelle 32 bits.

Ah merde, j'avas deja explique le big/litle endian!

Le truc de l'alignement des structures m'a saoule a comprendre, mais bon j'arrive a quelque chose.
Pour l'instant, je met le header du programme, ainsi que l'octet de la commande de chaque ligne, me reste a mettre l'octet de codage des parametres (presque fait) et les octets des parametres (pas gagne, mais je me suis simplifie la tache).

Bon, apres y a la machine virtuelle a faire!
Pis le champion.
Reste plus que 3 jours.

Non seulement tu reexpliques le big/little mais t'as mis du temps a repondre pertinemment a ma question Ok, sur 4 octets donc.

C'est quoi cet alignement des structures ? T'arrives a faire le calcul des labels (et pourquoi sur l'exemple, ils font un offset a partir de la fin ??) ?


Bref, comme d'hab, tu mets pas bcp de retour .. c'est vraiment la peine de commencer a regarder tes trucs

Scuse.
L'alignement des structures, c'est que la taille de la structure n'est pas egale a la somme des elements qu'elle contient, car chaque element doit etre un multiple de 4 (machine en 32 bits).
Donc dans ma structure j'ai par exemple le nom du programme codee dans un char* de taille 128+1 (le '\0' de la fin). Comme 129 % 4 != 0, le champs tiendra 132 octets en memoire.
Voila, c'est pas difficile, c'est juste que j'ai le cerveau un peu lent pour comprendre ce genre de trucs.

Pour les labels, je recupere leur position a un premier parsage du fichier, qui me sers a recuperer le nom du programme (la ligne .name) et le commentaire (la ligne .comment), ainsi que sa taille finale (en calculant le nombre d'octets necessaires a chaque ligne). De ce fait, a chaque fin de ligne, j'ai la position de debut de la ligne suivante, ce qui me donne donc la position du label s'il y en a un. Et a la fin, j'ai la taille du fichier. Donc apres avoir mis dans un tableau de liste chainee mes labels avec leur adresse (adresse commencant a partir du debut des instructions, le header n'est pas pris en compte), je peut donc calculer leur position.

Dans le programme, lorsqu'on appel un label, on le fait en relatif, mais a partir de l'octet de l'instruction (dans l'exemple a partir de zjmp). Comme dans l'exemple le label "live" se trouve avant qu'il soit appele, 5 octets plus precisement (tu peut compter), on va donc mettre -5. Converti en hexa, -5 donne ff fb sur 2 octets (ff fb + 4 = ff ff, +1 = 00 00).
Pourquoi ils sont codes sur 2 octets seulement, j'en sais rien. Mais bon, on fait avec.
Pis deole pur le peu de retour, maintenant que je me suis mis dedans, ca avance, donc je passe plus trop.
Pis je croyais que vous aviez lache l'affaire!

Non, y a pas de mal .. je comprends que tu ais pas trop le temps de passer non plus

Allez, courage !

Et je pense que je passerais moins!

Bon sinon je viens de rentrer (1h15 pour rentrer! Ca demotive, j'ai plus envie de bosser ), et j'ai toujours autant de mal a passer de qwerty en azerty!

Dit, tu a un MSN iray?
Parcque sur le forum je pense que je vais passer de moins en moins, mais ca m'empechera pas d'avoir un truc a demander des fois (en plus du ca va? )

J'ai un MSN mais je l'ouvre rarement .. (seulement de temps en temps sous gaim en fait) ..

Je suis plus souvent sur Yahoo! .. mais de facon generale, ancien IRC-aholic, j'essaie d'eviter les chats

Bon aye, le compilateur est fini. Pb : le resultat donne n'est pas du tout celui escompte! Je n'ai pas la meme taille de fichier, pas les bons paramettres, ...

Allez, on reprend tout a 0!