Esta página lista os formatos de instrução usados pelo formato Dalvik Executable e pelo bytecode Dalvik. Ele deve ser usado em conjunto com o documento de referência de bytecode .
Descrições bit a bit
A primeira coluna na tabela de formatos lista o layout bit a bit do formato. Consiste em uma ou mais "palavras" separadas por espaço, cada uma das quais descreve uma unidade de código de 16 bits. Cada caractere em uma palavra representa quatro bits, lidos dos bits mais altos para os mais baixos, com barras verticais (" |
") intercaladas para auxiliar na leitura. Letras maiúsculas em sequência a partir de " A
" são usadas para indicar campos dentro do formato (que então são definidos pela coluna de sintaxe). O termo " op
" é usado para indicar a posição de um opcode de oito bits dentro do formato. Um zero barrado (" Ø
") é usado para indicar que todos os bits devem ser zero na posição indicada.
Na maioria das vezes, as letras procedem de unidades de código anteriores para unidades de código posteriores e de ordem inferior para ordem superior dentro de uma unidade de código. No entanto, existem algumas exceções a essa regra geral, que são feitas para que a nomenclatura de partes de significado semelhante seja a mesma em diferentes formatos de instrução. Esses casos são anotados explicitamente nas descrições de formato.
Por exemplo, o formato " B|A| op CCCC
" indica que o formato consiste em duas unidades de código de 16 bits. A primeira palavra consiste no opcode nos oito bits inferiores e um par de valores de quatro bits nos oito bits superiores; e a segunda palavra consiste em um único valor de 16 bits.
Códigos de formato
A segunda coluna na tabela de formatos indica o identificador abreviado do formato, que é usado em outros documentos e no código para identificar o formato.
A maioria dos IDs de formato consiste em três caracteres, dois dígitos seguidos por uma letra. O primeiro dígito indica o número de unidades de código de 16 bits no formato. O segundo dígito indica o número máximo de registros que o formato contém (máximo, pois alguns formatos podem acomodar um número variável de registros), com a designação especial " r
" indicando que um intervalo de registros está codificado. A letra final indica semi-mnemonicamente o tipo de qualquer dado extra codificado pelo formato. Por exemplo, o formato " 21t
" tem comprimento dois, contém uma referência de registro e, adicionalmente, contém um destino de ramificação.
Os formatos de link estático sugeridos têm um sufixo " s
" adicional, totalizando quatro caracteres. Da mesma forma, os formatos de link "inline" sugeridos têm um sufixo " i
" adicional. (Neste contexto, a vinculação em linha é como a vinculação estática, exceto com vínculos mais diretos com a implementação de uma máquina.) Finalmente, alguns formatos sugeridos excêntricos (por exemplo, " 20bc
") incluem dois pedaços de dados que são representados em seu ID de formato .
A lista completa de letras de código de tipo é a seguinte. Observe que alguns formulários têm tamanhos diferentes, dependendo do formato:
Mnemônico | Tamanhos de bits | Significado |
---|---|---|
b | 8 | imediato assinado por |
c | 16, 32 | índice de pool constante |
f | 16 | constantes de interface (usadas apenas em formatos vinculados estaticamente) |
h | 16 | h com sinal imediato (bits de alta ordem de um valor de 32 ou 64 bits; bits de baixa ordem são todos 0 ) |
eu | 32 | i nt com sinal imediato ou float de 32 bits |
eu | 64 | imediato com sinal longo ou duplo de 64 bits |
m | 16 | constantes do método m (usadas apenas em formatos vinculados estaticamente) |
n | 4 | n ibble assinado imediato |
s | 16 | horta assinada imediata |
t | 8, 16, 32 | alvo do ramo |
x | 0 | sem dados adicionais |
Sintaxe
A terceira coluna da tabela de formatos indica a sintaxe orientada a humanos para instruções que usam o formato indicado. Cada instrução começa com o opcode nomeado e é opcionalmente seguida por um ou mais argumentos, separados por vírgulas.
Sempre que um argumento se refere a um campo da primeira coluna, a letra desse campo é indicada na sintaxe, repetida uma vez para cada quatro bits do campo. Por exemplo, um campo de oito bits rotulado " BB
" na primeira coluna também seria rotulado " BB
" na coluna de sintaxe.
Argumentos que nomeiam um registrador têm a forma " v X
". O prefixo " v
" foi escolhido em vez do mais comum " r
" exatamente para evitar conflitos com arquiteturas (não virtuais) nas quais o formato Dalvik Executable pode ser implementado que usam o prefixo " r
" para seus registradores. (Ou seja, esta decisão permite falar de registros virtuais e reais juntos sem a necessidade de circunlóquios.)
Os argumentos que indicam um valor literal têm a forma " #+ X
". Alguns formatos indicam literais que possuem apenas bits diferentes de zero em seus bits de ordem superior; para estes, os zeros são representados explicitamente na sintaxe, embora não apareçam na representação bit a bit.
Os argumentos que indicam um deslocamento de endereço de instrução relativo têm a forma " + X
".
Argumentos que indicam um índice de pool de constante literal têm a forma " kind @ X
", onde " kind
" indica qual pool de constante está sendo referido. Cada opcode que usa tal formato permite explicitamente apenas um tipo de constante; veja a referência opcode para descobrir a correspondência. Os tipos de pool de constantes são " string
" (índice de pool de strings), " type
" (índice de pool de tipos), " field
" (índice de pool de campos), " meth
" (índice de pool de métodos) e " site
" (índice de site de chamada ).
Semelhante à representação de índices de pool constantes, também existem formas sugeridas (opcionais) que indicam deslocamentos ou índices pré-vinculados. Existem dois tipos de valores pré-vinculados sugeridos: deslocamentos vtable (indicados como " vtaboff
") e deslocamentos de campo (indicados como " fieldoff
").
Nos casos em que um valor de formato não faz parte explicitamente da sintaxe, mas escolhe uma variante, cada variante é listada com o prefixo " [ X = N ]
" (por exemplo, " [A=2]
") para indicar a correspondência .
Os formatos
Formato | EU IRIA | Sintaxe | Opcodes notáveis cobertos |
---|---|---|---|
N / D | 00x | N/A | pseudo-formato usado para opcodes não utilizados; sugerido para uso como o formato nominal para um opcode de ponto de interrupção |
ØØ| operação | 10x | op | |
B|A| operação | 12x | op vA, vB | |
11n | op vA, #+B | ||
AA| operação | 11x | operação op | |
10t | op +AA | Vá para | |
ØØ| op AAAA | 20t | op +AAAA | goto/16 |
AA| op BBBB | 20 aC | op AA, kind@BBBB | formato sugerido para erros de verificação determinados estaticamente; A é o tipo de erro e B é um índice em uma tabela apropriada ao tipo (por exemplo, referências de método para um erro sem tal método) |
AA| op BBBB | 22x | op vAA, vBBBB | |
21t | op vAA, +BBBB | ||
21s | op vAA, #+BBBB | ||
21h | op vAA, #+BBBB0000op vAA, #+BBBB000000000000 | ||
21c | op vAA, digite @BBBBop vAA, campo@BBBBop vAA, method_handle@BBBBop vAA, proto@BBBBop vAA, string@BBBB | check-cast classe const const-method-handle tipo de método const const-string | |
AA| op CC|BB | 23x | op vAA, vBB, vCC | |
22b | op vAA, vBB, #+CC | ||
B|A| op CCCC | 22t | op vA, vB, +CCCC | |
22s | op vA, vB, #+CCCC | ||
22c | op vA, vB, type@CCCCop vA, vB, campo@CCCC | instancia de | |
22cs | op vA, vB, fieldoff@CCCC | formato sugerido para instruções de acesso a campos vinculados estaticamente de formato 22c | |
ØØ| op AAAA o AAAA oi | 30t | op +AAAAAAAA | goto/32 |
ØØ| op AAAA BBBB | 32x | op vAAAA, vBBBB | |
AA| op BBBB lo BBBB oi | 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 @BBBBA escolha inusitada das letras aqui reflete o desejo de fazer com que a contagem e o índice de referência tenham a mesma etiqueta do formato 3rc. | |
35ms | [ 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@BBBBA escolha inusitada das letras aqui reflete o desejo de fazer com que a contagem e o índice de referência tenham a mesma etiqueta do formato 3rms. | formato sugerido para instruções invoke-virtual e invoke-super vinculadas estaticamente do formato 35c | |
35mi | [ 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@BBBBA escolha inusitada das letras aqui reflete o desejo de fazer com que a contagem e o índice de referência tenham a mesma etiqueta do formato 3rmi. | formato sugerido para instruções de invoke-static e invoke-virtual vinculadas em linha do formato 35c | |
AA| op BBBB CCCC | 3rc | op {vCCCC .. vNNNN}, meth@BBBBop {vCCCC .. vNNNN}, site@BBBBop {vCCCC .. vNNNN}, digite@BBBB onde | |
3rms | op {vCCCC .. vNNNN}, vtaboff@BBBB onde | formato sugerido para instruções invoke-virtual e invoke-super vinculadas estaticamente do formato 3rc | |
3rmi | op {vCCCC .. vNNNN}, inline@BBBB onde | formato sugerido para instruções de invoke-static e invoke-virtual vinculadas em linha do formato 3rc | |
A|G| op 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 | invocar-polimórfico |
AA| op BBBB CCCC HHHH | 4cc | op> {vCCCC .. vNNNN}, meth@BBBB, proto@HHHH onde | invocar-polimórfico/range |
AA| op BBBB lo BBBB BBBB BBBB oi | 51l | op vAA, #+BBBBBBBBBBBBBBBB | const-wide |