Est-ce que Bytecode et la langue d'assemblage sont la même chose?

Question

La question peut sembler étrange, mais j'essaie toujours de saisir les concepts de machines virtuelles. J'ai lu plusieurs réponses, mais je ne comprends toujours pas si le bytecode Java (et MSIL aussi) est le même que le langage d'assemblage. Autant que je sache, le code à la fois et l'assemblage sont compilés en code machine, si bien qu'en termes d'abstraction, ils sont au même niveau, c'est-à-dire un pas au-dessus du code machine. Le bytecode n'est donc qu'un langage d'assemblage, c'est-à-dire une forme lisible par l'homme de code machine. Si oui, pourquoi le langage d'assemblage est-il toujours utilisé? Pourquoi ne pas programmer en bytecode (qui est portable sur différentes machines) au lieu du langage d'assemblage (qui est spécifique à une architecture de machine unique)? Merci

Answer 1

n °

bytecode Java est un langage de programmation binaire, pas « forme lisible par l'homme », à moins que vous considérez groupe de numéro lisible, ou si vous utilisez désassembleur pour inverser dans les mnémoniques texte bytecode, ou éventuellement la Formulaire source Java lui-même. L'assemblage est généralement un mnémonique textuel des instructions réelles de la machine cible, mappées 1: 1 l'une avec l'autre, donc une instruction dans la source assembleur se traduira directement en une instruction de code machine (bien que quelques exceptions existent avec certains processeurs et assembleurs , comme par exemple de nombreux assembleurs RISC traduiront "charger le registre avec la valeur immédiate" en plusieurs instructions si nécessaire - pour charger toute valeur immédiate, alors que le code machine natif ne peut charger que des bits particuliers, et vous devez composer la valeur entière). Le bytecode Java est un langage d'abstraction de très haut niveau comparé à la plupart des codes machine des processeurs, avec un chevauchement très minime des instructions et du modèle de mémoire. La seule similitude est que bytecode est stocké sous forme binaire, tout comme le code machine.

---

modifier:

La machine virtuelle Java est interprète en principe, à savoir. il traduit le bytecode à la volée en code machine. C'est la chose, qui est faite dans d'autres langages par le compilateur pendant la compilation. Les JVM modernes ne sont pas des interpréteurs pures classiques, mais utilisent le compilateur "JIT" (Just In Time) pour compiler de petits morceaux de bytecode java en code machine natif, juste avant son exécution, en utilisant des caches pour éviter une deuxième compilation de déjà Les fichiers .class connus, ainsi que le suivi à l'exécution des données de performance pour mieux instruire le compilateur JIT, devraient être optimisés fortement (exécution souvent ou boucle interne), et devraient être compilés dès que possible, sans se concentrer sur les performances. Donc, avec la JVM moderne, il est difficile de parler d'interprètes, c'est une solution complexe et sophistiquée. C# va assez souvent même un peu plus loin, en fournissant parfois une partie des binaires pré-compilés en code machine pour les plates-formes communes (ayant la forme de bytecode uniquement comme une solution de repli pour les plates-formes peu communes).

Rien de tout cela (pas même similaire) se produit avec le code machine. Il s'exécute simplement sur le CPU.

Answer 2

Un langage d'assemblage est un langage de texte lisible par l'homme conçu pour être assemblé en un binaire. Chaque ligne source correspond directement à un bloc de sortie binaire (par exemple, une instruction x86 de longueur variable), sans dépendre des lignes précédentes. (Je ne suis pas sûr si Java bytecode asm est sensible au contexte, je ne l'ai pas utilisé).

par exemple. mov eax, 1234 s'assemble aux mêmes 5 octets sans tenir compte des autres lignes de source qui l'entourent. (Ignorer les constantes nommées et les macros assembleur, bien sûr).La signification par défaut de "assembly language" (celui décrit le wiki tag assembly) est le langage assembleur de code machine CPU, où les octets assemblés dans le fichier de sortie sont des instructions et des données pour un exécutable natif pour une sorte de CPU/microprocesseur.

D'autres types de langages d'assemblage existent, comme l'assemblage de java bytecode où les octets assemblés dans le fichier de sortie sont au format Java .class et peuvent être exécutés par une machine virtuelle Java. (@ La réponse de Ped7g sur ce point, explique comment une JVM peut optimiser lors de la traduction du bytecode Java en code machine natif.)

Tout est dans le langage texte pour que l'assembleur assemble des octets. dans le fichier de sortie.

---

Vous pouvez avoir un langage d'assemblage pour tout type de format de fichier binaire, même non exécutable. Un exemple simple: un langage d'assemblage pour un format de fichier image fixe bitmap, où vous pouvez utiliser des couleurs nommées (comme midnight blue) pour chaque pixel. L'assembleur assemblerait des bits (au lieu de seulement des octets entiers comme des langages d'assemblage normaux) dans le fichier de sortie. Dans un cas plus complexe, vous pouvez imaginer un langage d'assemblage H.264, où vous utilisez une syntaxe de texte pour décrire le codage des en-têtes et de chaque macrobloc.

Dans ce cas, vous devez concevoir l'assembleur pour effectuer la compression finale CABAC ou CAVLC des données de macrobloc assemblées dans un flux de bits, au lieu de le décrire comme faisant partie du langage d'assemblage. Ce serait comme un assembleur x86 qui produirait des binaires gzippés: assembler dans un flux de dégonflement.

---

Une caractéristique clé d'un langage d'assemblage est que il est assez proche du format code machine qu'un désassembleur peut transformer un binaire en signal asm qui ressemble à ce qui a été assemblé en premier lieu (mais sans des commentaires, des noms d'étiquettes ou des macros, bien sûr). C'est pourquoi C et Java sont considérés comme des langages de plus haut niveau que l'ensemble binaire/assembleur que leurs compilateurs produisent en sortie.

Answer 3

Je vois votre point, et si vous plisser les yeux et rendre les choses un peu floue alors oui absolument. JAVA bytecode et Python équivalent et Pascals et quelques autres sont peut-être juste des définitions de code machine et leurs compilateurs compilent à ce code machine. Et ce code machine s'exécute nativement sur une machine. À ce jour, ces machines sont virtuelles, et elles le seront probablement toujours, et c'est ce que vous obtenez d'autres personnes ici. L'assemblage est le code machine de la forme lisible par l'homme, les bits et octets qui ne sont pas aussi faciles à lire mais faciles à lire par les machines. JAVA, etc., le code machine est en partie juste un autre jeu d'instructions, et il existe d'autres jeux d'instructions basés sur la pile qui sont implémentés directement dans le matériel, c'est une approche générique très simple pour un jeu d'instructions. Mais ils ont des appels système de haut niveau, bien plus élevés que ceux du CISC, et c'est là que le problème vient en les implémentant dans la logique. Il n'y a pas de raison de microcoder quelque chose comme ça, la façon dont vous l'approchez est de créer une machine virtuelle en utilisant l'ensemble d'instructions natif (compilé à partir d'un langage de haut niveau non-JAVA très probablement).

Si c'était vraiment juste un autre ensemble d'instructions alors absolument vous pourriez créer du silicium pour cela.Mais même si vous le pouvez, cela ne signifie pas que nous devrions abandonner tous les autres ensembles d'instructions que nous avons. Pour commencer, les outils JAVA semblent être fiers qu'ils n'optimisent pas. Donc, vous commencez avec des programmes lents et ne faites que les rendre un peu plus rapides. Quand d'autres langages sur du matériel natif sont beaucoup moins coûteux en ressources et en énergie. Les inventeurs avaient le désir de le faire, et nous font croire que c'est arrivé, ARM Jazelle, et d'autres. Dans le cas d'ARM Jazelle, le silicium prend les octets en logique, mais il les regarde dans une table qui est constituée de code machine natif. Les processeurs ARM qui revendiquent le support de Jazelle sont faux car vous devez acheter un blob logiciel d'ARM pour le faire fonctionner, et un certain nombre d'autres JVM sont plus rapides et plus efficaces (parfois gratuitement) que le logiciel ARM Jazelle payant. Donc c'était un échec, et c'était bidon de toute façon.

Oui, c'est un langage qui est compilé dans un code machine. Ce code machine est exécuté sur une machine. La différence est que les machines virtuelles ne sont pas implémentées dans le silicium (tout comme le code machine qui est implémenté sur un processeur microcodé est, (grin)), et ne le sera probablement pas.