Visão geral das convenções ABI x64

Este tópico descreve a ABI (interface binária de aplicativo) básica para x64, a extensão de 64 bits para a arquitetura x86. Ele aborda tópicos como a convenção de chamada, layout de tipo, uso de pilha e registro e muito mais.

Convenções de chamada x64

Duas diferenças importantes entre x86 e x64 são:

• Funcionalidade de endereçamento de 64 bits
• Dezesseis registros de 64 bits para uso geral.

Considerando o conjunto de registros expandido, o x64 usa a convenção de chamada __fastcall e um modelo de tratamento de exceções baseado em RISC.

A convenção __fastcall usa registros para os quatro primeiros argumentos e o registro de ativação para passar mais argumentos. Para obter detalhes sobre a convenção de chamada x64, incluindo uso de registro, parâmetros de pilha, valores retornados e desenrolamento de pilha, confira a convenção de chamada x64.

Habilitar a otimização do compilador x64

A seguinte opção do compilador ajuda você a otimizar seu aplicativo para x64:

• /favor (otimizar para especificações da arquitetura)

Tipo x64 e layout de armazenamento

Esta seção descreve o armazenamento de tipos de dados para a arquitetura x64.

Tipos escalares

Embora seja possível acessar dados com qualquer alinhamento, alinhe os dados no limite natural deles ou um múltiplo do limite natural deles, para evitar perda de desempenho. Enumerações são inteiros constantes e são tratados como inteiros de 32 bits. A tabela a seguir descreve a definição de tipo e o armazenamento recomendado para dados, pois se refere ao alinhamento usando os seguintes valores de alinhamento:

• Byte – 8 bits
• Palavra – 16 bits
• Doubleword – 32 bits
• Quadword – 64 bits
• Octaword – 128 bits

Tipo escalar	Tipos de dados do C	Tamanho de armazenamento (em bytes)	Alinhamento recomendado
INT8	char	1	Byte
UINT8	unsigned char	1	Byte
INT16	short	2	Word
UINT16	unsigned short	2	Word
INT32	int, long	4	Doubleword
UINT32	unsigned int, unsigned long	4	Doubleword
INT64	__int64	8	Quadword
UINT64	unsigned __int64	8	Quadword
FP32 (precisão simples)	float	4	Doubleword
FP64 (precisão dupla)	double	8	Quadword
POINTER	*	8	Quadword
__m64	struct __m64	8	Quadword
__m128	struct __m128	16	Octaword

Layout de união e agregação x64

Outros tipos, como matrizes, structs e uniões, têm requisitos de alinhamento mais rigorosos que garantem a agregação consistente e a recuperação de dados e armazenamento de união. Aqui estão as definições para matriz, estrutura e união:

• Array

  Contém um grupo ordenado de objetos de dados adjacentes. Cada objeto é chamado de elemento. Todos os elementos dentro de uma matriz têm o mesmo tamanho e tipo de dados.

• Estrutura

  Contém um grupo ordenado de objetos de dados. Ao contrário dos elementos de uma matriz, os membros de uma estrutura podem ter tipos e tamanhos de dados diferentes.

• Union

  Um objeto que contém qualquer um dos membros nomeados de um conjunto. Os membros do conjunto nomeado podem ser de qualquer tipo. O armazenamento alocado para uma união é igual ao armazenamento necessário para o maior membro dessa união, além de qualquer preenchimento necessário para alinhamento.

A tabela a seguir mostra o alinhamento fortemente recomendado para os membros escalares de uniões e estruturas.

Tipo escalar	Tipo de dados em C++	Alinhamento Necessário
INT8	char	Byte
UINT8	unsigned char	Byte
INT16	short	Word
UINT16	unsigned short	Word
INT32	int, long	Doubleword
UINT32	unsigned int, unsigned long	Doubleword
INT64	__int64	Quadword
UINT64	unsigned __int64	Quadword
FP32 (precisão simples)	float	Doubleword
FP64 (precisão dupla)	double	Quadword
POINTER	*	Quadword
__m64	struct __m64	Quadword
__m128	struct __m128	Octaword

As seguintes regras de alinhamento agregado se aplicam:

• O alinhamento de uma matriz é o mesmo que o alinhamento de um dos elementos da matriz.

• O alinhamento do início de uma estrutura ou de uma união é o alinhamento máximo de qualquer membro individual. Cada membro dentro da estrutura ou união precisa ser colocado no alinhamento adequado, conforme definido na tabela anterior, o que pode exigir preenchimento interno implícito, dependendo do membro anterior.

• O tamanho da estrutura precisa ser um múltiplo integral do alinhamento dele, o que pode exigir preenchimento após o último membro. Como estruturas e uniões podem ser agrupadas em matrizes, cada elemento de matriz de uma estrutura ou união precisa começar e terminar no alinhamento adequado determinado anteriormente.

• É possível alinhar dados de maneira a exceder os requisitos de alinhamento, desde que as regras anteriores sejam mantidas.

• Um compilador individual pode ajustar o empacotamento de uma estrutura por motivos de tamanho. Por exemplo, /Zp (Alinhamento de membro struct) permite ajustar o empacotamento de estruturas.

Exemplos de alinhamento de estrutura x64

Os quatro exemplos a seguir declaram uma estrutura ou união alinhada, e as figuras correspondentes ilustram o layout dessa estrutura ou união na memória. Cada coluna em uma figura representa um byte de memória, e o número na coluna indica o deslocamento desse byte. O nome na segunda linha de cada figura corresponde ao nome de uma variável na declaração. As colunas sombreadas indicam o preenchimento necessário para alcançar o alinhamento especificado.

Exemplo 1

// Total size = 2 bytes, alignment = 2 bytes (word).

_declspec(align(2)) struct {
    short a;      // +0; size = 2 bytes
}

Exemplo 2

// Total size = 24 bytes, alignment = 8 bytes (quadword).

_declspec(align(8)) struct {
    int a;       // +0; size = 4 bytes
    double b;    // +8; size = 8 bytes
    short c;     // +16; size = 2 bytes
}

Exemplo 3

// Total size = 12 bytes, alignment = 4 bytes (doubleword).

_declspec(align(4)) struct {
    char a;       // +0; size = 1 byte
    short b;      // +2; size = 2 bytes
    char c;       // +4; size = 1 byte
    int d;        // +8; size = 4 bytes
}

Exemplo 4

// Total size = 8 bytes, alignment = 8 bytes (quadword).

_declspec(align(8)) union {
    char *p;      // +0; size = 8 bytes
    short s;      // +0; size = 2 bytes
    long l;       // +0; size = 4 bytes
}

Campos de bits

Os campos de bits de estrutura são limitados a 64 bits e podem ser do tipo int, int sem sinal, int64 ou int64 sem sinal. Campos de bits que cruzam o limite de tipo ignorarão bits para alinhar o campo de bits ao próximo alinhamento de tipo. Por exemplo, os campos de bits de inteiro podem não cruzar um limite de 32 bits.

Conflitos com o compilador x86

Os tipos de dados maiores que 4 bytes não são alinhados automaticamente na pilha quando você usa o compilador x86 para compilar um aplicativo. Como a arquitetura do compilador x86 é uma pilha alinhada de 4 bytes, qualquer coisa maior que 4 bytes, por exemplo, um inteiro de 64 bits, não pode ser alinhada automaticamente a um endereço de 8 bytes.

Trabalhar usando dados não atribuídos tem duas implicações.

• Pode levar mais tempo para acessar locais não atribuídos do que é necessário para acessar locais alinhados.

• Locais não atribuídos não podem ser usados em operações interligadas.

Se você precisar de um alinhamento mais estrito, use __declspec(align(N)) em suas declarações de variável. Isso faz com que o compilador alinhe dinamicamente a pilha para atender às suas especificações. No entanto, ajustar dinamicamente a pilha em tempo de execução pode causar uma execução mais lenta do aplicativo.

Uso do registro x64

A arquitetura x64 sustenta 16 registros de uso geral (de agora em diante, chamados de registros de inteiros), bem como para 16 registros XMM/YMM disponíveis para uso de ponto flutuante. Os registros voláteis são registros a partir do zero presumidos pelo chamador para serem destruídos em uma chamada. Os registros não voláteis são obrigados a manter seus valores em uma chamada de função e devem ser salvos pelo receptor da chamada se usados.

Registrar volatilidade e preservação

A tabela a seguir descreve como cada registro é usado nas chamadas de função:

Registrar-se	Status	Uso
RAX	Volátil	Registro de valores retornados
RCX	Volátil	Primeiro argumento inteiro
RDX	Volátil	Segundo argumento inteiro
R8	Volátil	Terceiro argumento inteiro
R9	Volátil	Quarto argumento inteiro
R10, R11	Volátil	Deve ser preservado, conforme a necessidade do chamador; usado em instruções syscall/sysret
R12, R15	Não volátil	Deve ser preservado pelo receptor da chamada
RDI	Não volátil	Deve ser preservado pelo receptor da chamada
RSI	Não volátil	Deve ser preservado pelo receptor da chamada
RBX	Não volátil	Deve ser preservado pelo receptor da chamada
RBP	Não volátil	Pode ser usado como um ponteiro de quadro; deve ser preservado pelo receptor da chamada
RSP	Não volátil	Ponteiro de pilha
XMM0, YMM0	Volátil	Primeiro argumento FP; primeiro argumento de tipo vetorial quando __vectorcall for usado
XMM1, YMM1	Volátil	Segundo argumento FP; segundo argumento de tipo vetorial quando __vectorcall for usado
XMM2, YMM2	Volátil	Terceiro argumento FP; terceiro argumento de tipo vetorial quando __vectorcall for usado
XMM3, YMM3	Volátil	Quarto argumento FP; quarto argumento de tipo vetorial quando __vectorcall for usado
XMM4, YMM4	Volátil	Deve ser preservado conforme necessário pelo chamador; quinto argumento de tipo vetorial quando __vectorcall for usado
XMM5, YMM5	Volátil	Deve ser preservado conforme necessário pelo chamador; sexto argumento de tipo vetorial quando __vectorcall for usado
XMM6:XMM15, YMM6:YMM15	Não volátil (XMM), Volátil (metade superior de YMM)	Precisa ser preservado pelo computador chamado. Os registros YMM devem ser preservados conforme necessário pelo chamador.

Na saída da função e na entrada da função para chamadas da Biblioteca de Runtime C e chamadas do sistema Windows, espera-se que o sinalizador de direção no registro de sinalizadores de CPU seja limpo.

Uso da pilha

Para obter detalhes sobre alocação de pilha, alinhamento, tipos de função e registros de ativação no x64, confira Uso da pilha x64.

Prólogo e epílogo

Cada função que aloca espaço de pilha, chama outras funções, salva registros não voláteis ou usa tratamento de exceção precisa ter uma caixa de diálogo cujos limites de endereço são descritos nos dados de desenrolamento associados à respectiva entrada de tabela de funções, bem como epílogos em cada saída para uma função. Para obter detalhes sobre o código de prólogo e de epílogo necessários em x64, confira Prólogo e epílogo x64.

Tratamento de exceções x64

Para obter informações sobre as convenções e estruturas de dados usadas para implementar o tratamento de exceções estruturados e o comportamento de tratamento de exceção C++ no x64, consulte o tratamento de exceção x64.

Intrínsecos e assembly embutido

Uma das restrições para o compilador x64 não é um suporte de assembler embutido. Isso significa que as funções que não podem ser gravadas em C ou C++ precisarão ser gravadas como sub-rotinas ou como funções intrínsecas compatíveis com o compilador. Determinadas funções são sensíveis ao desempenho, enquanto outras não. As funções sensíveis ao desempenho devem ser implementadas como funções intrínsecas.

Os intrínsecos compatíveis com o compilador são descritos Intrínsecos do compilador.

Formato de imagem x64

O formato de imagem executável x64 é PE32+. As imagens executáveis (DLLs e EXEs) são restritas a um tamanho máximo de 2 gigabytes, portanto, o endereçamento relativo com um deslocamento de 32 bits pode ser usado para lidar com os dados de imagem estáticos. Esses dados incluem a tabela de endereços de importação, constantes de cadeia de caracteres, dados globais estáticos e assim por diante.

Confira também

Convenções de chamada