Auf dieser Seite sind die Anweisungsformate aufgeführt, die vom Dalvik-Ausführformat (DEX) und vom Dalvik-Bytecode verwendet werden. Es ist in Verbindung mit dem Referenzdokument zum Bytecode gedacht.
Bitweise Beschreibungen
In der ersten Spalte der Formattabelle ist das binäre Layout des Formats aufgeführt. Sie besteht aus einem oder mehreren durch Leerzeichen getrennten „Wörtern“, die jeweils eine 16‑Bit-Codeeinheit beschreiben. Jedes Zeichen in einem Wort steht für vier Bits, die von den höheren zu den niedrigeren gelesen werden. Zur besseren Lesbarkeit sind vertikale Balken („|“) eingestreut. Großbuchstaben in der Reihenfolge ab „A“ geben Felder im Format an, die dann in der Syntaxspalte weiter definiert werden. Der Begriff „op“ gibt die Position eines 8‑Bit-Opcodes im Format an. Eine Null mit einem Schrägstrich („Ø“) gibt an, dass an der angegebenen Position alle Bits null sein müssen.
Die Beschriftung erfolgt in der Regel von früheren zu späteren Codeblöcken und innerhalb eines Codeblocks von niedriger zu höherer Ordnung. Es gibt jedoch einige Ausnahmen von dieser allgemeinen Regel, die dazu dienen, die Benennung von Teilen mit ähnlicher Bedeutung in verschiedenen Anweisungsformaten einheitlich zu gestalten. Diese Fälle sind in den Formatbeschreibungen ausdrücklich erwähnt.
Das Format „B|A|op CCCC“ gibt beispielsweise an, dass das Format aus zwei 16‑Bit-Codeeinheiten besteht. Das erste Wort besteht aus dem Opcode in den unteren acht Bits und einem Paar von vierbitigen Werten in den oberen acht Bits. Das zweite Wort besteht aus einem einzelnen 16‑Bit-Wert.
Format-IDs
Die zweite Spalte in der Formattabelle enthält die kurze Kennung für das Format, die in anderen Dokumenten und im Code verwendet wird, um das Format zu identifizieren.
Die meisten Format-IDs bestehen aus drei Zeichen, zwei Ziffern gefolgt von einem Buchstaben. Die erste Ziffer gibt die Anzahl der 16‑Bit-Codeeinheiten im Format an. Die zweite Ziffer gibt die maximale Anzahl der Register an, die das Format enthält (maximal, da einige Formate eine variable Anzahl von Registern aufnehmen können). Die spezielle Bezeichnung „r“ gibt an, dass ein Bereich von Registern codiert ist. Der letzte Buchstabe gibt semi-mnemonisch den Typ der zusätzlichen Daten an, die mit dem Format codiert sind. Das Format „21t“ hat beispielsweise eine Länge von zwei, enthält eine Registerreferenz und zusätzlich ein Verzweigungsziel.
Die vorgeschlagenen Formate für statische Verknüpfungen haben ein zusätzliches Suffix „s“, sodass sie insgesamt vier Zeichen lang sind. Ähnlich haben vorgeschlagene „Inline“-Verknüpfungsformate ein zusätzliches Suffix „i“. (In diesem Zusammenhang ist das Inline-Verknüpfen mit dem statischen Verknüpfen vergleichbar, mit der Ausnahme, dass es direktere Verbindungen zur Implementierung eines Computers gibt.)
Zum Schluss noch einige ungewöhnliche Formate (z.B.
„20bc“) enthalten zwei Daten, die beide in der Format-ID dargestellt sind.
Hier finden Sie eine vollständige Liste der Buchstaben für den Typcode. Einige Formulare haben je nach Format unterschiedliche Größen:
| Merkhilfe | Bitgrößen | Bedeutung |
|---|---|---|
| b | 8 | sofort signierte Byte |
| c | 16, 32 | Konstanter Poolindex |
| f | 16 | Interface-Konstanten (nur in statisch verknüpften Formaten verwendet) |
| h | 16 | Vorzeichenbehaftetes Hat (höchstwertige Bits eines 32‑ oder 64‑Bit-Werts; die niedrigwertigen Bits sind alle 0)
|
| i | 32 | vorzeichenbehaftete int oder 32‑Bit-Gleitkommazahl |
| l | 64 | Vorzeichenbehaftete long oder 64-Bit-Doppeltzahl |
| m | 16 | Methodenkonstanten (nur in statisch verknüpften Formaten verwendet) |
| n | 4 | sofort signierte nibble |
| s | 16 | sofort unterzeichnete short |
| t | 8, 16, 32 | branch target |
| x | 0 | keine zusätzlichen Daten |
Syntax
Die dritte Spalte der Formattabelle enthält die Syntax für Anweisungen, die das angegebene Format verwenden. Jede Anweisung beginnt mit dem benannten Opcode und wird optional von einem oder mehreren Argumenten gefolgt, die durch Kommas getrennt sind.
Wenn sich ein Argument auf ein Feld aus der ersten Spalte bezieht, wird der Buchstabe für dieses Feld in der Syntax angegeben und für jedes Feld mit vier Bits wiederholt. Ein 8‑Bit-Feld, das in der ersten Spalte mit „BB“ gekennzeichnet ist, wird in der Syntaxspalte ebenfalls mit „BB“ gekennzeichnet.
Argumente, die einen Registernamen enthalten, haben das Format „vX“. Das Präfix „v“ wurde anstelle des gängigeren „r“ gewählt, um Konflikte mit (nicht virtuellen) Architekturen zu vermeiden, in denen das Dalvik-Ausführbare-Format implementiert werden kann, das selbst das Präfix „r“ für seine Register verwendet. (Das heißt, diese Entscheidung ermöglicht es, sowohl über virtuelle als auch über reale Register zu sprechen, ohne Umschweife.)
Argumente, die einen Literalwert angeben, haben das Format „#+X“. Einige Formate geben Literale an, die nur Nichtnull-Bits in den höherwertigen Bits haben. Bei diesen werden die Nullen explizit in der Syntax dargestellt, auch wenn sie nicht in der bitweisen Darstellung erscheinen.
Argumente, die einen relativen Adressoffset angeben, haben die Form „+X“.
Argumente, die einen Literalkonstantenpoolindex angeben, haben das Format „kind@X“, wobei „kind“ angibt, auf welchen Konstantenpool verwiesen wird. Für jeden Opcode, der ein solches Format verwendet, ist ausdrücklich nur eine Art von Konstante zulässig. Die Zuordnung finden Sie in der Opcode-Referenz. Die Arten von Konstantenpools sind „string“ (Stringpoolindex), „type“ (Typpoolindex), „field“ (Feldpoolindex), „meth“ (Methodenpoolindex) und „site“ (Aufrufsstellenindex).
Ähnlich wie bei der Darstellung von Konstantenpool-Indizes werden auch (optionale) Formen vorgeschlagen, die vorverknüpfte Offset- oder Indizes angeben. Es gibt zwei Arten von vorgeschlagenen vorverbundenen Werten: VTable-Abweichungen (als „vtaboff“ gekennzeichnet) und Feldabweichungen (als „fieldoff“ gekennzeichnet).
Wenn ein Formatwert nicht explizit Teil der Syntax ist, sondern stattdessen eine Variante ausgewählt wird, wird jede Variante mit dem Präfix „[X=N]“ aufgeführt (z.B. „[A=2]“), um die Übereinstimmung anzugeben.
Formate
| Formatieren | ID | Syntax | Wichtige abgedeckte Opcodes |
|---|---|---|---|
| – | 00x | N/A |
Pseudoformat für nicht verwendete Opcodes; wird als Standardformat für einen Breakpoint-Opcode empfohlen |
| ØØ|op | 10-facher Zoom | op |
|
| B|A|op | 12-fach | op vA, vB |
|
| 11n | op vA, #+B |
||
| AA|op | 11-mal | op vAA |
|
| 10 t | op +AA |
goto | |
| ØØ|op AAAA | 20 t | op +AAAA |
goto/16 |
| AA|op BBBB | 20 bc | op AA, kind@BBBB |
Vorgeschlagenes Format für statisch ermittelte Überprüfungsfehler; A ist der Fehlertyp und B ist ein Index in einer typgerechten Tabelle (z.B. Methodenreferenzen für einen Fehler vom Typ „Methode nicht gefunden“) |
| AA|op BBBB | 22-mal | op vAA, vBBBB |
|
| 21 t | op vAA, +BBBB |
||
| 21 s | op vAA, #+BBBB |
||
| 21 Stunden | op vAA, #+BBBB0000op vAA, #+BBBB000000000000
|
||
| 21c | op vAA, type@BBBBop vAA, field@BBBBop vAA, method_handle@BBBBop vAA, proto@BBBBop vAA, string@BBBB
|
check-cast const-class const-method-handle const-method-type const-string |
|
| AA|op CC|BB | 23-mal | op vAA, vBB, vCC |
|
| 22b | op vAA, vBB, #+CC |
||
| B|A|op CCCC | 22t | op vA, vB, +CCCC |
|
| 22 s | op vA, vB, #+CCCC |
||
| 22c | op vA, vB, type@CCCCop vA, vB, field@CCCC
|
instance-of | |
| 22 cs | op vA, vB, fieldoff@CCCC |
Vorgeschlagenes Format für Anweisungen für den statisch verknüpften Feldzugriff im Format 22c | |
| ØØ|op AAAAlo AAAAhi | 30 Tbit/s | op +AAAAAAAA |
goto/32 |
| ØØ|op AAAA BBBB | 32x | op vAAAA, vBBBB |
|
| AA|op BBBBlo BBBBhi | 31i | op vAA, #+BBBBBBBB |
|
| 31t | op vAA, +BBBBBBBB |
||
| 31c | op vAA, string@BBBBBBBB |
const-string/jumbo | |
| A|G|op BBBB F|E|D|C | 35c | [A=5] op {vC, vD, vE, vF, vG},
meth@BBBB[ A=5] op {vC, vD, vE, vF, vG},
site@BBBB[ A=5] op {vC, vD, vE, vF, vG},
type@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@BBBBDie ungewöhnliche Schriftart hier spiegelt den Wunsch wider, dass die Zählung und der Referenzindex dasselbe Label wie im Format 3rc haben. |
|
| 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@BBBBDie ungewöhnliche Schriftart soll die Übereinstimmung der Beschriftung für die Zählung und den Referenzindex mit dem Format „3rms“ verdeutlichen. |
Vorgeschlagenes Format für statisch verknüpfte invoke-virtual- und invoke-super-Anweisungen im Format 35c
|
|
| 56 km | [A=5] op {vC, vD, vE, vF, vG},
inline@BBBB[ A=4] op {vC, vD, vE, vF},
inline@BBBB[ A=3] op {vC, vD, vE},
inline@BBBB[ A=2] op {vC, vD},
inline@BBBB[ A=1] op {vC},
inline@BBBBDie ungewöhnliche Schriftart hier spiegelt den Wunsch wider, dass die Zählung und der Referenzindex dasselbe Label wie im Format 3rmi haben. |
Vorgeschlagenes Format für Inline-invoke-static- und invoke-virtual-Anleitungen im Format 35c
|
|
| AA|op BBBB CCCC | 3rc | op {vCCCC .. vNNNN}, meth@BBBBop {vCCCC .. vNNNN}, site@BBBBop {vCCCC .. vNNNN}, type@BBBBwobei |
|
| 3rms | op {vCCCC .. vNNNN}, vtaboff@BBBBwobei |
Vorgeschlagenes Format für statisch verknüpfte invoke-virtual und invoke-super-Anweisungen im Format 3rc
|
|
| 3rmi | op {vCCCC .. vNNNN}, inline@BBBBwobei |
Vorgeschlagenes Format für Inline-invoke-static- und invoke-virtual-Anleitungen im Format 3rc
|
|
| A|G|op BBBB F|E|D|C HHHH | 45 cm³ |
[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
|
invoke-polymorphic |
| AA|op BBBB CCCC HHHH | 4rcc |
op> {vCCCC .. vNNNN}, meth@BBBB, proto@HHHH
wobei |
invoke-polymorphic/range |
| AA|op BBBBlo BBBB BBBB BBBBhi | 51 l | op vAA, #+BBBBBBBBBBBBBBBB |
const-wide |