1

Lorsque la liaison d'adresse n'est pas possible au moment de la compilation, elle est effectuée au moment du chargement/de la liaison ou de l'exécution, pour associer les adresses relatives (ou peut-être appelables) aux adresses physiques réelles. De plus, l'unité centrale convertit également ces adresses relatives en adresses logiques avant la liaison pour les adresses physiques.Adresses relatives générées par le compilateur et comment sont-elles représentées dans le bytecode (de préférence java)?

La conversion de logique en physique est un concept connu pour moi. Mais, j'ai été confus au sujet de ces adressage relatif (AFAIK, ils ont appelé relatif parce qu'ils sont donnés/assignés par rapport à zéro par le compilateur). Je ne suis pas sûr quelles adresses relatives sont utilisées pour (dans un bytecode) ou si elles sont vraiment nécessaires, ou elles sont même identiques aux adresses logiques?

+1

Vous avez tiré la question dans le pied en introduisant RELOCATABLE. C'est un concept indépendant qui est bien au-delà de votre compréhension à ce stade. –

+0

@BruceDavidWilner Autant que je m'en souvienne. Il peut y avoir deux types de liaison d'adresse. Relatif à logique, et logique à relatif. Ans parfois l'adresse relative et les termes d'adresse relocalisables sont utilisés de manière interchangeable. C'est pourquoi j'ai utilisé ce terme. – zgulser

+0

@BruceDavidWilner Mais je suis d'accord avec vous. Relocatable plus fait référence à des adresses encore non résolues (si vous le vouliez). – zgulser

Répondre

1

Vous mélangez beaucoup de concepts. Une adresse relative est juste une adresse qui a besoin d'une adresse de base à convertir en une adresse absolue. Cette conversion peut se produire de plusieurs façons. Un est en train de les convertir au moment du chargement, mais ils peuvent aussi être utilisés avec des instructions CPU qui supportent intrinsèquement l'adressage relatif en effectuant le calcul juste quand l'emplacement mémoire doit être accédé.

Si un système d'exploitation prend en charge la mémoire virtuelle, toutes les adresses utilisées dans un processus ordinaire sont logiques, qu'elles soient référencées relatives ou absolues. La conversion d'adresses logiques en adresses physiques est en dehors de la portée de l'application et indépendante de tout autre concept auquel vous faites référence dans votre question.

Le format de fichier de classe ne fonctionne pas en termes d'emplacements de mémoire.

Si vous souhaitez appliquer les termes «absolu» et «relatif» à ce niveau supérieur, les indices de pool constant sont absolus car ils ne nécessitent pas d'index de base pour identifier l'index réel. Cependant, lorsque vous souhaitez trouver l'emplacement de la mémoire dans le fichier chargé, vous devez non seulement utiliser l'adresse à laquelle le fichier de classe a été chargé, mais également analyser l'intégralité du pool de constantes jusqu'à l'élément souhaité. différentes tailles d'octets. Pour cette raison, les articles ne sont généralement pas regardés du tout. Au lieu de cela, l'ensemble du pool est converti en une représentation spécifique JVM ayant des tailles d'éléments constantes en une seule passe et plus tard, la JVM peut rechercher des entrées de cette table, qui est indépendante de l'emplacement mémoire du fichier classe.Dans les instructions de code octet, les décalages relatifs sont utilisés, ce qui nécessite d'ajouter la position de l'instruction actuelle pour obtenir une position absolue, mais notez comment cela ne rentre pas dans les concepts nommés dans votre question. Les positions absolues sont toujours des positions dans une séquence d'instructions et, par conséquent, par rapport à l'emplacement mémoire du code quand on parle d'adresses. De plus, les décalages relatifs ne sont pas utilisés car "la liaison n'est pas possible au moment de la compilation", les positions absolues résultantes sont connues au moment de la compilation. Le jeu d'instructions Java byte code est juste défini pour utiliser des décalages relatifs pour permettre un code plus compact. Du point de vue d'un ensemble d'instructions, nous pourrions dire qu'il supporte intrinsèquement l'adressage relatif. La façon dont la JVM implémente réellement son exécution dépend de la JVM.

Depuis you mentioned the JVM’s native code generation, lorsqu'une machine virtuelle Java génère du code natif, elle connaît l'adresse cible du code et peut décider librement d'utiliser des adresses relatives ou absolues, comme elle convient. Comme déjà mentionné, tout ce qui est décrit ci-dessus se passe dans un processus, donc si le système d'exploitation utilise la mémoire virtuelle, tout est en termes d'adresses logiques qui peuvent être adaptées par le système d'exploitation, par ex. via MMU. Ces concepts ne sont pas liés.

+0

J'ai déjà lu à propos de la relation entre un processus et ses espaces d'adresses logiques et physiques. Merci pour le rappel. Plus précisément, j'essaie de lire un fichier de classe décodé (gen par le compilateur) et de voir beaucoup de nombres faisant référence à un pool constant, un tableau de variables locales, un tableau de bytecodes, etc. Donc, inévitablement, j'essaie d'associer ces nombres (offsets relatifs, si vous voulez) avec leurs homologues logiques, en supposant qu'ils n'ont pas encore lié par le compilateur. Et, d'après vos vues ci-dessus, et comme d'autres l'ont dit, c'est fait par JVM. – zgulser

+0

De plus, je me référais à des adresses absolues comme des adresses physiques et vous avez eu votre mot à dire «cela ne rentre pas dans les concepts nommés dans votre question». – zgulser

+0

On ne sait pas ce que vous voulez dire par "pas encore lié par le compilateur" quand vous faites référence à des nombres dans un fichier de classe. Ils ont tous été liés par le compilateur car c'était en fait le compilateur qui leur a donné un sens.Cela devient encore plus étrange quand vous dites que vous regardez des fichiers de classe * décodés * comme alors, c'est la décision du décodeur de vous montrer un nombre au lieu de l'élément réel (par exemple des éléments de pool constant). Un fichier de classe est [juste un fichier] (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html) que vous pouvez analyser sans savoir ce qu'une JVM fera avec. – Holger

1

Le bytecode Java fonctionne à un niveau d'abstraction beaucoup plus élevé que le code machine natif. Il n'y a aucune notion d'adresses mémoire - les méthodes sont référencées symboliquement.

La meilleure façon de penser au bytecode Java est qu'il est pratiquement 1: 1 avec la version initiale du langage Java. Le compilateur fait certaines choses comme la conversion de variables locales en index numériques et la conversion de flux de contrôle en gotos, mais pour la plupart, il est très similaire au code original.

La JVM est responsable de l'interprétation ou de la compilation du bytecode en code natif lors de l'exécution.

+0

Merci. J'avais en fait le concept de l'abstraction JVM et des références symboliques. Mais j'essaie d'être un peu plus profond. Tout d'abord, quelles sont exactement ces adresses relatives dans le bytecode? Par exemple, est-ce que les références de pool de constantes (# 3, # 20, etc.) ou les index de tableaux bytecode (ceux du côté gauche des instructions 0:, 2: 4 :) peuvent être donnés à titre d'exemple? Deuxièmement, le moteur d'exécution JVM convertit le bytecode en code natif/machine au préalable. Ces codes natif sont-ils directement exécutables ou doivent-ils être filtrés pour les lier à leurs adresses physiques? – zgulser

1

Obtenir les adresses de mémoire des objets est réellement inutile dans Java: car la JVM gère tout cela. En d'autres termes: la machine virtuelle Java «place» les objets où ils devraient être; et ils peuvent même être "déplacés"; par exemple lors de la collecte des ordures. En d'autres termes: en tant que programmeur Java, vous ne vous en souciez pas. Et si vous vous en souciez; il n'y a rien que vous puissiez faire à ce sujet.

+0

Oui, je m'en soucie :). Et je ne veux pas faire d'autres choses. J'essaie juste de comprendre ce qui se passe sous le capot. – zgulser

+1

Ensuite, vous devrez probablement faire un plongeon très profond dans les détails d'implémentation d'une implémentation JVM. – GhostCat

+0

J'ai remarqué :). – zgulser