Cette page répertorie les formats d'instructions utilisés par le format exécutable Dalvik (DEX) et le bytecode Dalvik. Il est destiné à être utilisé conjointement avec le document de référence du bytecode .
Descriptions au niveau du bit
La première colonne du tableau des formats répertorie la disposition bit à bit du format. Il se compose d'un ou plusieurs « mots » séparés par des espaces, chacun décrivant une unité de code de 16 bits. Chaque caractère d'un mot représente quatre bits, lus des bits forts aux bits faibles, avec des barres verticales (" |
") intercalées pour faciliter la lecture. Les lettres majuscules consécutives à partir de « A
» sont utilisées pour indiquer les champs dans le format (qui sont ensuite définis plus en détail par la colonne de syntaxe). Le terme « op
» est utilisé pour indiquer la position d'un opcode de huit bits dans le format. Un zéro barré (« Ø
») est utilisé pour indiquer que tous les bits doivent être nuls à la position indiquée.
Pour la plupart, le lettrage passe des unités de code antérieures aux unités de code ultérieures, et d'ordre inférieur à celui d'ordre élevé au sein d'une unité de code. Cependant, il existe quelques exceptions à cette règle générale, qui visent à ce que la dénomination des parties de signification similaire soit la même dans les différents formats d'instructions. Ces cas sont mentionnés explicitement dans les descriptions de format.
Par exemple, le format « B|A| op CCCC
» indique que le format est constitué de deux unités de code de 16 bits. Le premier mot est constitué de l'opcode dans les huit bits de poids faible et d'une paire de valeurs de quatre bits dans les huit bits de poids fort ; et le deuxième mot est constitué d'une seule valeur de 16 bits.
Formater les identifiants
La deuxième colonne du tableau des formats indique l'identifiant court du format, qui est utilisé dans d'autres documents et dans le code pour identifier le format.
La plupart des identifiants de format sont constitués de trois caractères, deux chiffres suivis d'une lettre. Le premier chiffre indique le nombre d'unités de code de 16 bits dans le format. Le deuxième chiffre indique le nombre maximum de registres que contient le format (maximum, puisque certains formats peuvent accueillir un nombre variable de registres), avec la désignation spéciale « r
» indiquant qu'une plage de registres est codée. La dernière lettre indique de manière semi-mnémonique le type de toute donnée supplémentaire codée par le format. Par exemple, le format « 21t
» est de longueur deux, contient une référence de registre et contient en outre une cible de branchement.
Les formats de liens statiques suggérés ont un suffixe « s
» supplémentaire, ce qui leur donne un total de quatre caractères. De même, les formats de liens « en ligne » suggérés ont un suffixe « i
» supplémentaire. (Dans ce contexte, les liens en ligne sont comme les liens statiques, sauf avec des liens plus directs avec l'implémentation d'une machine.) Enfin, quelques formats suggérés étranges (par exemple, " 20bc
") incluent deux éléments de données qui sont tous deux représentés dans leur ID de format. .
La liste complète des lettres de code de type est la suivante. Notez que certains formulaires ont des tailles différentes, selon le format :
Mnémonique | Tailles de bits | Signification |
---|---|---|
b | 8 | immédiat signé par octet |
c | 16, 32 | indice de pool constant |
F | 16 | constantes d' interface (utilisées uniquement dans les formats liés statiquement) |
h | 16 | h at signé immédiat (bits de poids fort d'une valeur de 32 ou 64 bits ; les bits de poids faible sont tous 0 ) |
je | 32 | i nt signé immédiatement, ou float 32 bits |
je | 64 | immédiat signé long , ou double 64 bits |
m | 16 | constantes de méthode (utilisées uniquement dans les formats liés statiquement) |
n | 4 | immédiat signé n ibble |
s | 16 | immédiat signé s court |
t | 8, 16, 32 | cible de la branche |
X | 0 | pas de données supplémentaires |
Syntaxe
La troisième colonne du tableau de format indique la syntaxe orientée vers l'humain pour les instructions qui utilisent le format indiqué. Chaque instruction commence par l'opcode nommé et est éventuellement suivie d'un ou plusieurs arguments, eux-mêmes séparés par des virgules.
Chaque fois qu'un argument fait référence à un champ de la première colonne, la lettre de ce champ est indiquée dans la syntaxe, répétée une fois pour quatre bits du champ. Par exemple, un champ de huit bits intitulé « BB
» dans la première colonne sera également étiqueté « BB
» dans la colonne de syntaxe.
Les arguments qui nomment un registre ont la forme " v X
". Le préfixe " v
" a été choisi à la place du " r
" plus courant précisément pour éviter tout conflit avec les architectures (non virtuelles) sur lesquelles le format Dalvik Executable pourrait être implémenté et qui utilisent elles-mêmes le préfixe " r
" pour leurs registres. (Autrement dit, cette décision permet de parler ensemble des registres virtuels et réels sans avoir besoin de circonlocutions.)
Les arguments qui indiquent une valeur littérale ont la forme " #+ X
". Certains formats indiquent des littéraux qui n'ont que des bits non nuls dans leurs bits de poids fort ; pour ceux-ci, les zéros sont représentés explicitement dans la syntaxe, même s'ils n'apparaissent pas dans la représentation bit à bit.
Les arguments qui indiquent un décalage relatif d'adresse d'instruction ont la forme " + X
".
Les arguments qui indiquent un index de pool constant littéral ont la forme " kind @ X
", où " kind
" indique à quel pool constant il est fait référence. Chaque opcode qui utilise un tel format n'autorise explicitement qu'un seul type de constante ; voir la référence de l'opcode pour comprendre la correspondance. Les types de pool de constantes sont « string
» (index du pool de chaînes), « type
» (index du pool de types), « field
» (index du pool de champs), « meth
» (index du pool de méthodes) et « site
» (index du site d'appel ).
Semblable à la représentation des indices de pool constants, il existe également des formes suggérées (facultatives) qui indiquent des compensations ou des indices préliés. Il existe deux types de valeurs préliées suggérées : les décalages de table virtuelle (indiqués par " vtaboff
") et les décalages de champ (indiqués par " fieldoff
").
Dans les cas où une valeur de format ne fait pas explicitement partie de la syntaxe mais sélectionne plutôt une variante, chaque variante est répertoriée avec le préfixe " [ X = N ]
" (par exemple, " [A=2]
") pour indiquer la correspondance. .
Formats
Format | IDENTIFIANT | Syntaxe | Opcodes notables couverts |
---|---|---|---|
N / A | 00x | N/A | pseudo-format utilisé pour les opcodes inutilisés ; suggéré pour utilisation comme format nominal pour un opcode de point d'arrêt |
ØØ| op | 10x | op | |
B|UNE| op | 12x | op vA, vB | |
11h | op vA, #+B | ||
AA| op | 11x | op vAA | |
10 tonnes | op +AA | aller à | |
ØØ| sur AAAA | 20 tonnes | op +AAAA | aller à/16 |
AA| sur BBBB | 20 avant JC | op AA, gentil@BBBB | format suggéré pour les erreurs de vérification déterminées de manière statique ; A est le type d'erreur et B est un index dans une table appropriée au type (par exemple, des références de méthode pour une erreur sans méthode) |
AA| sur BBBB | 22x | op vAA, vBBBB | |
21 jours | op vAA, +BBBB | ||
21s | op vAA, #+BBBB | ||
21h | op vAA, #+BBBB0000op vAA, #+BBBB000000000000 | ||
21c | op vAA, tapez@BBBBop vAA, champ@BBBBop vAA, method_handle@BBBBop vAA, proto@BBBBop vAA, chaîne @BBBB | chèque-cast classe const const-méthode-handle type de méthode const chaîne const | |
AA| sur CC|BB | 23x | op vAA, vBB, vCC | |
22b | op vAA, vBB, #+CC | ||
B|UNE| sur CCCC | 22t | op vA, vB, +CCCC | |
22s | op vA, vB, #+CCCC | ||
22c | op vA, vB, tapez@CCCCop vA, vB, champ@CCCC | exemple de | |
22cs | op vA, vB, fieldoff@CCCC | format suggéré pour les instructions d'accès aux champs liées statiquement du format 22c | |
ØØ| op AAAA bas AAAA salut | 30 tonnes | op +AAAAAAAA | aller à/32 |
ØØ| sur AAAA BBBB | 32x | op vAAAA, vBBBB | |
AA| sur BBBB là BBBB salut | 31i | op vAA, #+BBBBBBBB | |
31 jours | op vAA, +BBBBBBBB | ||
31c | op vAA, chaîne @BBBBBBBB | const-string/jumbo | |
UNE|G| sur BBBB F|E|D|C | 35c | [ A=5 ] op {vC, vD, vE, vF, vG}, méth@BBBB[ A=5 ] op {vC, vD, vE, vF, vG}, site@BBBB[ A=5 ] op {vC, vD, vE, vF, vG}, tapez@BBBB[ A=4 ] op {vC, vD, vE, vF}, kind @BBBB[ A=3 ] op {vC, vD, vE}, kind @BBBB[ A=2 ] op {vC, vD}, kind @BBBB[ A=1 ] op {vC}, kind @BBBB[ A=0 ] op {}, kind @BBBBLe choix inhabituel du lettrage traduit ici une volonté de faire en sorte que le décompte et l'index de référence aient le même label qu'au format 3rc. | |
35 ms | [ A=5 ] op {vC, vD, vE, vF, vG}, vtaboff@BBBB[ A=4 ] op {vC, vD, vE, vF}, vtaboff@BBBB[ A=3 ] op {vC, vD, vE}, vtaboff@BBBB[ A=2 ] op {vC, vD}, vtaboff@BBBB[ A=1 ] op {vC}, vtaboff@BBBBLe choix inhabituel du lettrage traduit ici une volonté de faire en sorte que le décompte et l'index de référence aient le même label qu'au format 3rms. | format suggéré pour les instructions invoke-virtual et invoke-super statiquement au format 35c | |
35km | [ A=5 ] op {vC, vD, vE, vF, vG}, en ligne@BBBB[ A=4 ] op {vC, vD, vE, vF}, en ligne@BBBB[ A=3 ] op {vC, vD, vE}, en ligne@BBBB[ A=2 ] op {vC, vD}, en ligne@BBBB[ A=1 ] op {vC}, en ligne@BBBBLe choix inhabituel du lettrage traduit ici une volonté de faire en sorte que le décompte et l'index de référence aient le même label qu'au format 3rmi. | format suggéré pour les instructions invoke-static et invoke-virtual liées en ligne du format 35c | |
AA| sur BBBB CCCC | 3rc | op {vCCCC .. vNNNN}, meth@BBBBop {vCCCC .. vNNNN}, site@BBBBop {vCCCC .. vNNNN}, tapez@BBBB où | |
3 heures | op {vCCCC .. vNNNN}, vtaboff@BBBB où | format suggéré pour les instructions invoke-virtual et invoke-super statiquement au format 3rc | |
3rmi | op {vCCCC .. vNNNN}, en ligne@BBBB où | format suggéré pour les instructions invoke-static et invoke-virtual au format 3rc | |
UNE|G| sur BBBB F|E|D|C HHHH | 45cc | [ A=5 ] op {vC, vD, vE, vF, vG}, meth@BBBB, proto@HHHH[ A=4 ] op {vC, vD, vE, vF}, meth@BBBB, proto@HHHH[ A=3 ] op {vC, vD, vE}, meth@BBBB, proto@HHHH[ A=2 ] op {vC, vD}, meth@BBBB, proto@HHHH[ A=1 ] op {vC}, meth@BBBB, proto@HHHH | invoquer-polymorphique |
AA| sur BBBB CCCC HHHH | 4rcc | op> {vCCCC .. vNNNN}, meth@BBBB, proto@HHHH où | invoquer-polymorphique/gamme |
AA| sur BBBB lo BBBB BBBB BBBB salut | 51l | op vAA, #+BBBBBBBBBBBBBBBB | à l'échelle constante |