Discussion :

[JOYE]

[Bonjour,

Je n'y connais pas grand chose en langages assemblés. Il semble qu'il faille écrire un source qui est ensuite compilé. Arrêtez moi si je me trompe...

Mais existe t-il des interpréteurs de langage assemblés ?

Eric

[Selenite]

Peut-être, en tant qu'émulateur.

[Juju_41]

Mais existe t-il des interpréteurs de langage assemblés ?

... l'interpréteur d'un langage assemblé c'est le processeur lui-même ! L'assembleur est un langage compilé et non interprété.

Il existe peut-être une sorte d'émulateur qui interprête le langage assemblé mais je n'en connais pas.

Un débogueur peut s'apparenter à un interpréteur de langage assemblé mais il ne faut pas confondre ...

[2PluS4]

Et bochs alors ? C un émulateur d'asm non ?

[- Robby -]

Salut !

Ouf ! La question de Joye est pertinente et intéressante.
et certainement pas bete ... pas du tout.
Avant tout, je rectifie : Non, le processeur n'est pas l'interpréteur du language assemblé. Le processeur exécute du code machine. Code machine et code assembleur sont deux choses différentes. Le processeur ne connait même pas l'existence du code assembleur, il ne connait que le code machine ... tout le reste lui est inconnu.
Bon ... ceci dit, je continue.
Il existe, pour les languages de haut niveau, deux écoles.
L'interpréteur et le compilateur. Plus le language est évolué, plus les instructions sont puissantes. L'interpréteur, une a une, traduit chaque instruction du language évolué en bloc de code machine et ensuite exécute ce bloc de code machine. Ensuite il passe a l'instruction du language évolué suivante et recommence ... jusqu'a la dernière.
Le compilateur, lui, traduit " toutes " les instructions du language évolué en un seul gros bloc de code machine et ensuite exécute tout d'un coup.
Un interpréteur, c'est un peu un compilateur " ligne par ligne ".
La différence qui oppose interpréteur et compilateur est essentiellement un facteur de vitesse d'exécution. En principe, un interpréteur sera toujours pluis lent qu'un compilateur ... mais plus le language utilisé est puissant, plus cette différence diminue. Interpréter du code assembleur, d'un point théorique, pourquoi pas. Chaque instruction assembleur, une a une, serait traduite dans son correspondant machine et ensuite exécutée. Pourquoi pas dans le fond ! ... mais cela prendrait un temps énorme !
Pour traduire et exécuter une seule instruction assembleur, par exemple mov eax,ebx , il faudrait des centaines d'instruction machine appartenant au programme qui interprète ... l'interpréteur luiu même. Alors qu'en principe, 95 % des instructions assembleur, correspondent chacune a une instruction machine ..... d'ou son nom de language de bas niveau ... le plus bas possible d'ailleurs. Ce qui veut dire que ..... si un language de haut niveau prend 2 fois plus de temps a etre exécuté par un interpréteur plutot qu'un compilateur, le language assembleur, lui, mettra peut etre 100 ou 500 fois plus de temps a etre exécuté par un interpréteur plutot que par un compilateur. C'est absurde !!! l'avantage essentiel du language assembleur est la vitesse et l'optimisation. Son interprétation jette tout ca a l'égout. Voila. Donc, théoriquement, ta question est même très intéressante ... pratiquement, cela n'aurait pas de sens. Bon, maintenant faut pas confondre avec le mot "émulateur" aussi. Ca, c'est encore autre chose ! Mais un réel interpréteur de language assembleur, ca n'existe pas ...

[Smortex]

Je complèterai la réponse de - Robby - tout en essayant de répondre a la question de l'émulation qui vient tout naturellement en lisant ce sujet.

Il existe des émulateurs de PC... et on peux les classer dans deux catégories bien distincte :
La premère est la plus répandue inclue les émulateurs où le processeurs "émulé" EST le processeur du PC : c'est le vrai processeur qui exécute les instructions. C'est par exemple le cas de VMWare. La deuxième catégorie est celle où l'émulateur émule aussi le microprocesseur, tel que Bosch...

Les deux méthodes ont des avantages et inconvégnients : Si on émule le processeur, on va bien moins vite, mais on peut émuler un autre microprocesseur (Un AMD64bit par exemple)...

De ce fait, les deux types d'émulateurs peuvent trouver leur utilité selon les circonstances...

[Paul Atreide]

Si on veut jouer sur les mots, on peut même dire que le processeur est un interpréteur de langage binaire. En effet quand une instruction binaire arrive dans un processeur (Intel ou AMD) il faut d'abord qu'il la comprenne (ie qu'il l'interprète). Les processeurs actuels d'ordinateur sont de type CISC : ils connaissent énormément d'instructions élémentaires. Bref quand le code binaire correspondant à MOV EAX,EBX arrive, il faut que le processeur détermine qu'il veut faire un MOV et quels opérandes il devra utiliser. C'est d'ailleurs ce qui fait que les "gros" processeurs sont plus lents que les processeurs de type RISC qui ne connaissent que peu d'instructions. Ce type de processeur n'a pas besoin d'interpréter les codes binaires qui arrivent, il les exécute directement.

[2PluS4]

Les processeurs actuels d'ordinateur sont de type CISC

Non pas du tt !!! Il existe pleins (euh) de processeurs RISC sur le marché (UltraSPARC, etc...)

ref quand le code binaire correspondant à MOV EAX,EBX arrive, il faut que le processeur détermine qu'il veut faire un MOV et quels opérandes il devra utiliser.

En faisant en plus toutes les modifications d'adressage quand le paging et/ou la segmentation sont activés

[Smortex]

Aller, on pousse encore :

CISC : Complete Instruction Set Computers : Cela concerne les microprocessuers et microcontrôleurs tels que les x86, 68HC11, ... Les instructions prennent généralement plusieurs cycles d'horloge (On peut pas vraiment donner de moyenne... Ca dépends entre autre des modes d'adressage... Donc on va dire qu'au minimum, une instruction prends 2-3 cycles d'horloge)... Ces micros possèdent des centaines d'instructions... Les commandes et les données arrivent "à la queuleuleu"...

RISC : Reduced Insctruction Set Computers : Ca conserve les Alpha (A vérifier, j'ai un doute d'un coup), les PIC, ... Les instructions prennent généralement un seul cycle d'horloge, les sauts conditiennels deux si il y a effectivement un saut. Il y a très peu d'instructions (a peine quelques dizaines)... La vitesse accrue est due au fait que les commandes et les données arrivent par des chemins différents, simultanément... Tout est donc lu d'un seul coup...

Wala.... J'ai essayé de faire simple pour que les non-initiés ne soient pas perdus... On trouve plein d'infos sur le Web, n'hésitez pas a chercher si je vous ait mis l'eau à la bouche

Bon développement !


-- Edit --

Ce que j'apelle COMMANDE et DONNEE :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
LDAA         #$FF
Commande     Donnée

[Smortex]

oops

Je me suis embrouillé dans les architectures de Von Neumann et Harvard. Il y a aissi biend des micro RISC que CISC qui utilisent deux bus porur transférer les commandes et les données...

Désolé...

[Didier Derain]

Je suis tomber ici par erreur mais il existe bien des interpreteurs pour le language assembleur (language machine compilé) il suffit de regarder les emulateur pour atari amiga gameboy ... qui interpretre et execute sur un pc du langauge compiler pour une autre plate forme. pour ce qui est de l'emulation d'un pc (pas de windows) il existe un outil sous linux (dons j'ai perdu le non) qui emule une machine complete...

[2PluS4]

Je suis tomber ici par erreur mais il existe bien des interpreteurs pour le language assembleur (language machine compilé) il suffit de regarder les emulateur pour atari amiga gameboy ... qui interpretre et execute sur un pc du langauge compiler pour une autre plate forme. pour ce qui est de l'emulation d'un pc (pas de windows)

Peut être mais...

Ce que tu décris la, ce sont des émulateurs, c pas pareil !!!

il existe un outil sous linux (dons j'ai perdu le non) qui emule une machine complete...

Oui il en existe des tas (style vmwre ou bochs) et ils fonctionnent aussi sous win$