Emulateur pour Linux et x86-64

Version imprimable

04/04/2008, 08h54
fgh39

Emulateur pour Linux et x86-64

Bonjour

Je connais moyennement l'asm sur des "vieux" cpu Motorola 8/16bits du genre 68xx et pour déboguer j'utilisais fréquement les ports sur lesquel je transférais des états qui m'aidaient au débug.
Depuis peux je m'intéresse a l'asm si possible sous Linux (semble + simple a utiliser ) cependant je cherche un programme qui m'aiderait a simuler ou voire les registres du cpu ou des variable (peu importe)
Le but est de m'initier a l'asm PC tranquillement mais sûrement.
Existe t il un émulateur ou quelque chose d'équivalent ?
Aussi je compte l'utiliser sur une distro x86-64, mis a part la taille de certains registres et ceux des datas qui seront sur 8 octets, y a t il des choses a savoir
? :)

Merci d'avance.
07/04/2008, 12h25
Neitsa

Citation:

Envoyé par fgh39

Depuis peux je m'intéresse a l'asm si possible sous Linux (semble + simple a utiliser ) cependant je cherche un programme qui m'aiderait a simuler ou voire les registres du cpu ou des variable (peu importe)

Existe t il un émulateur ou quelque chose d'équivalent ?

Il y a une grosse différence entre l'émulation et l'affichage de l'état d'un programme à un instant t.

L'émulation x86 sur x86 est peu intéressante (le seul cas pratique que je vois est l'exécution dans une sandbox d'un code [potentiellement] malveillant).

Le plus simple, pour afficher l'état d'un programme au moment où tu le souhaites est de passer le programme dans un debugger.

Sous unixoïdes (Unix, Linux and co.) le plus connu est gdb pour lequel il existe de nombreux front-end (DDD, Eclipse CDT, Xcode debugger, GDBtk/Insight, etc.)

Citation:

Aussi je compte l'utiliser sur une distro x86-64, mis a part la taille de certains registres et ceux des datas qui seront sur 8 octets, y a t il des choses a savoir
? :)

Merci d'avance.

A part les registres supplémentaires et surtout la convention d'appel unique (et différente des conventions 16/32 bits), pas grand chose de fondamentalement différent.

cf. la FAQ assembleur : http://asm.developpez.com/faq/?page=fx64

P.S : L'asm x86 sous Windows ne me paraît pas plus difficile à utiliser que sous Linux, c'est kif-kif (après tout on a les mêmes instructions). Il y a peut être même plus d'outils (IDE, Debuggers, etc.) sous Win que sous Linux. M'enfin ça reste un point de vue personnel et forcément subjectif.
09/04/2008, 18h59
dapounet

Citation:

Envoyé par Neitsa

A part les registres supplémentaires et surtout la convention d'appel unique (et différente des conventions 16/32 bits), pas grand chose de fondamentalement différent.

Je trouve plutôt qu'il y pas mal de changement, pour le passage 16->32 il suffisait d'utiliser tout le temps des opérandes 32 bits et l'adressage était simplifié mais quand on commence en 64 bits on ne sait jamais quelle taille d'opérande il vaut mieux utiliser. Il y a aussi les instructions supprimées comme PUSHAD/POPAD, les versions courtes de INC/DEC...
10/04/2008, 10h35
Neitsa

Hello,

Citation:

Envoyé par dapounet

Je trouve plutôt qu'il y pas mal de changement, pour le passage 16->32 il suffisait d'utiliser tout le temps des opérandes 32 bits et l'adressage était simplifié mais quand on commence en 64 bits on ne sait jamais quelle taille d'opérande il vaut mieux utiliser.

De mon point de vue, ça ne change pas grand chose. En 32 bits on travaille en 32 bits (plus précisément : avec des données ayant une taille de 32 bits) si c'est la taille de données que l'on manipule. Rien n'empêche, si les données sont plus petites, d'utiliser des registres (ou pointeur sur données) 16 ou 8 bits. C'est dépendant du contexte.

En 64 bits, même chose, tout va dépendre en fait de ce qu'on manipule. Ceci dit, il me semble plus avantageux, même si les données sont plus petites (32, 16, 8), de privilégier la taille du bus et de travailler avec du 64 bits en 64 bits.

(je n'ai pas compris pourquoi tu dis "l'adressage était simplifié". A part le RIP relaive addressing, je n'ai pas vue de changement quant à l'adressage. Mais j'ai peut être loupé qque chose.)

Citation:

Il y a aussi les instructions supprimées comme PUSHAD/POPAD, les versions courtes de INC/DEC...

Elles ne sont pas légions et sont, pour la majorité, rarement utilisées. J'ai pris mon manuel et fait une liste des instructions illégales en 64 bits :

Citation:

PUSH ES
POP ES
PUSH SS
POP SS
DAA
AAA
INC Reg (forme courte)
PUSHA / PUSHAD
POPA / POPAD
BOUND
ARPL
LES
LDS
AAM
AAD
PUSH CS
PUSH DS
POP DS
DAS
AAS
DEC Reg (forme courte)
CALLF Ptr16:16 / CALLF Ptr16:32
INTO
JMP far

A part PUSHAD / POPAD et les formes courtes de DEC et INC, les autres instructions sont très rarement utilisées.

Oui, je suis d'accord Dapounet, il y a bien eu des changements, mais (de mon point de vue) je ne trouve rien de fondamentalement différent (je tiens à appuyer sur "fondamentalement") à part les registres supplémentaires et surtout la nouvelle convention d'appel. Et encore, cette dernière est plus le fait des O.S que du mode 64 bits en lui-même.

Ceci dit, j'ai peut être mal interprété ta première partie sur la difficulté du choix de la taille d'opérande.

En tout cas le débat est lancé à propos du 64 bits sur x86 ;)
10/04/2008, 20h21
dapounet

Citation:

Envoyé par Neitsa

En 32 bits on travaille en 32 bits (plus précisément : avec des données ayant une taille de 32 bits) si c'est la taille de données que l'on manipule. Rien n'empêche, si les données sont plus petites, d'utiliser des registres (ou pointeur sur données) 16 ou 8 bits. C'est dépendant du contexte.

Le problème c'est qu'utiliser une partie d'un registre 32 bits peut créer des stalls donc on essaie de toujours utiliser des opérandes 32b. C'est presque tout le temps possible et ça évite aussi les préfixes des instructions 16b.
Il n'y a pas ce problème-là quand on écrit dans un registre 32b en mode 64b parce que la partie haute est d'office mise à zéro. Par contre en utilisant des instructions 64b pour rien on prend un octet de préfixe en plus. Apparemment ça peut même être plus mais j'ai l'impression que FASM foire un peu quand il compte les octets, en regardant à l'éditeur hexadécimal je ne tombe pas sur la même chose. Je n'ai pas le temps maintenant mais je vérifierai plus tard.

Citation:

Envoyé par Neitsa

(je n'ai pas compris pourquoi tu dis "l'adressage était simplifié". A part le RIP relaive addressing, je n'ai pas vue de changement quant à l'adressage. Mais j'ai peut être loupé qque chose.)

Je voulais parler de l'adressage 32b qui est beaucoup plus flexible que le 16b, c'est le truc qui m'a vraiment donné envie de m'y mettre (à l'école on apprenait à faire des vieux programmes DOS).

D'un autre côté l'appel de fonctions est beaucoup plus simple et un débutant peut commencer à les utiliser directement alors qu'en 32b en général on commence avec des macros. Sur un système 64 bits il n'y a plus non plus de raison d'apprendre à utiliser le FPU que beaucoup de gens trouvent tordu à cause de la "pile".
Je trouve aussi qu'il n'y a pas tant de changement que ça mais j'ai quand même été surpris quand j'ai vu ce que c'était en pratique : d'après les tests hardware que j'avais lu c'était juste des nouveaux registres, plus de mémoire adressable et basta...