O que o processador faz com o seu código

Boas práticas de código têm impacto direto no desempenho a nível de máquina, mas essa relação raramente é ensinada de forma explícita. A maioria das discussões sobre qualidade de código para no design, na legibilidade ou na manutenibilidade. O que acontece abaixo disso, no processador, raramente entra na conversa.

Esta série constrói essa conexão, partindo do funcionamento do processador em termos que qualquer programador pode acompanhar. Um código que aproveita o que o processador oferece não precisa ser complexo. Em muitos casos, ele é mais direto do que seu equivalente descuidado. Tornar essa relação concreta exige partir do que o processador vê.

O programador escreve código em termos de variáveis nomeadas, estruturas de controle, chamadas de função e abstrações que o ambiente de programação fornece. O processador opera com endereços de memória, registradores numerados e operações individuais codificadas em sequências de bits. Entre um mundo e o outro existe uma cadeia de tradução que o compilador, o sistema operacional e o próprio hardware executam de forma praticamente automática.

Essa camada automática é desejável na maior parte do tempo. Ela permite que programadores pensem em termos de problemas e soluções sem precisar administrar cada detalhe do hardware. O problema começa quando alguma coisa vai mal de forma não óbvia. Um programa que deveria ser rápido apresenta latência inexplicável. Um serviço que parece correto em testes se comporta de forma inesperada sob carga. A depuração dessas situações exige descer pela cadeia de abstração até o nível onde o comportamento é determinado, que frequentemente é o nível do hardware.

O ponto de partida é a memória. Do ponto de vista do processador, código e dados habitam o mesmo espaço de endereços, e o ciclo de busca e execução é o mecanismo pelo qual ele avança instrução por instrução. Examinado com números, esse ciclo expõe o desperdício que levou engenheiros a projetar a pipeline.

A memória como sequência de endereços

A memória de um computador é um espaço de armazenamento endereçável por byte. Cada posição nesse espaço tem um endereço numérico único, e o processador acessa qualquer posição informando seu endereço. A memória não distingue entre dados e instruções. Tanto o código de um programa quanto os valores que ele manipula existem nesse mesmo espaço, em regiões separadas por convenção e pelo sistema operacional.

flowchart TB
    classDef code fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
    classDef data fill:#d1fae5,stroke:#059669,color:#064e3b

    subgraph MEM["Memória — sequência contínua de endereços"]
        subgraph CODE["Região de código"]
            I1["0x0400  mov eax, edi"]:::code
            I2["0x0403  add eax, esi"]:::code
            I3["0x0406  ret"]:::code
        end
        subgraph DATA["Região de dados"]
            V1["0x1000  00 00 00 2A  ← int x = 42"]:::data
            V2["0x1004  00 00 00 00  ← int y = 0"]:::data
        end
    end

    CODE ~~~ DATA

Quando um programador declara int x = 42; em Java ou em C, o que acontece por baixo é que o compilador e o runtime reservam quatro bytes em alguma posição da memória e registram que o nome x se refere àquela posição. O valor 42 é armazenado como a sequência de bits correspondente à representação inteira de 42 nesses quatro bytes. Toda vez que o código subsequente menciona x, o compilador traduz essa referência para o endereço de memória que ele reservou, ou para o registrador onde o valor foi carregado temporariamente.

Endereço     Conteúdo
0x1000       00 00 00 2A    ← variável x (valor 42, em hexadecimal 0x2A)
0x1004       00 00 00 00
0x1008       ...

O mesmo raciocínio se aplica ao código. As instruções que o compilador gera para executar uma operação de soma são bytes armazenados em endereços de memória. O processador busca esses bytes, interpreta cada sequência como uma instrução específica e executa a operação correspondente. A distinção entre "código" e "dados" existe no modelo do programador, mas no nível do hardware ambos são bytes em endereços de memória.

Essa organização tem implicação direta em como a execução funciona. O processador precisa de um mecanismo para saber qual endereço contém a próxima instrução a ser executada. Sem esse mecanismo, ele não saberia por onde começar e não teria como avançar de uma instrução para a próxima.

O contador de programa

O mecanismo que controla a posição atual de execução é o contador de programa (PC, de program counter), também chamado de instruction pointer (IP) em arquiteturas como x86. O PC é um registrador interno do processador que armazena o endereço de memória da instrução que será buscada em seguida.

A operação mais comum do PC é o incremento automático. Depois de buscar uma instrução no endereço armazenado no PC, o processador avança o PC para o endereço da instrução seguinte. Esse avanço não é necessariamente de um byte. Instruções têm tamanhos variados dependendo da arquitetura. Em arquiteturas de comprimento fixo como ARM, cada instrução ocupa exatamente quatro bytes, então o PC avança quatro a cada ciclo. Em arquiteturas de comprimento variável como x86, o processador precisa primeiro decodificar a instrução para saber quantos bytes ela ocupa e só então avança o PC pelo valor correto.

O PC também muda de maneiras não triviais. Uma instrução de desvio incondicional como goto ou jmp armazena no PC o endereço do destino do desvio. Uma instrução de desvio condicional faz o mesmo se a condição for satisfeita, ou avança normalmente se não for. Uma chamada de função armazena no PC o endereço de entrada da função e empilha o endereço de retorno na pilha de chamadas para que a execução possa retornar ao ponto correto quando a função terminar.

flowchart TD
    A["PC = endereço inicial"] --> B["Buscar instrução no endereço do PC"]
    B --> C{"Tipo de instrução?"}
    C -->|"instrução normal"| D["PC = PC + tamanho da instrução"]
    C -->|"desvio condicional (verdadeiro)"| E["PC = endereço de destino"]
    C -->|"desvio condicional (falso)"| D
    C -->|"chamada de função"| F["Empilhar retorno
PC = endereço da função"]
    C -->|"retorno de função"| G["PC = desempilhar endereço de retorno"]
    D --> H["Executar instrução"]
    E --> H
    F --> H
    G --> H
    H --> B

O PC é o fio condutor da execução. Todo o comportamento de um programa, incluindo laços, condicionais, chamadas de função e tratamento de exceções, se manifesta como uma sequência de modificações no valor do PC ao longo do tempo. Quando um depurador mostra a linha atual do programa, ele está essencialmente consultando o PC e mapeando o endereço de volta para o código-fonte.

De código Java a instruções de máquina

Um método simples em Java como o abaixo parece trivial do ponto de vista do código-fonte.

public static int soma(int a, int b) {
    return a + b;
}

Quando esse método passa pelo compilador Java (javac), ele é convertido em bytecode JVM, uma representação intermediária independente de plataforma. O bytecode para esse método tem a seguinte forma.

iload_0      // empurrar argumento 'a' na pilha de operandos
iload_1      // empurrar argumento 'b' na pilha de operandos
iadd         // somar os dois valores do topo da pilha
ireturn      // retornar o resultado

Cada linha do bytecode é uma instrução para a máquina virtual Java. O prefixo i indica operação sobre inteiros. iload_0 carrega o primeiro argumento do método (posição 0 no array de variáveis locais) na pilha de operandos. iload_1 carrega o segundo. iadd consome os dois valores do topo da pilha e empurra a soma. ireturn retorna o valor do topo da pilha para quem chamou o método.

Quando o JIT (Just-In-Time compiler) da JVM decide compilar esse método para código de máquina nativo, a tradução vai um passo adiante. Para uma arquitetura x86-64, o resultado se aproxima das instruções abaixo.

; soma(int a, int b) — argumentos em edi e esi (convenção System V AMD64)
mov  eax, edi      ; mover 'a' para o registrador de retorno
add  eax, esi      ; somar 'b' ao valor de 'a'
ret                ; retornar (resultado já em eax)

O compilador percebeu que os dois argumentos já estão em registradores pela convenção de chamada (o primeiro argumento em edi, o segundo em esi) e que o valor de retorno deve estar em eax. Ele copiou a para eax e adicionou b. Três instruções de máquina para um método de duas linhas de Java.

Esse exemplo é simples para tornar a tradução visível. Métodos com laços, condicionais, chamadas de outros métodos e operações sobre objetos geram dezenas ou centenas de instruções de máquina, e o compilador aplica várias transformações para reduzir esse número ou reorganizar a sequência para melhor desempenho. O ponto importante é que qualquer programa, independentemente de quanto de código-fonte ele contenha, se reduz a uma sequência de instruções de máquina armazenadas em endereços de memória e executadas pelo processador uma por vez a partir do endereço no PC.

Código, pilha e heap

As instruções de máquina do programa, as variáveis locais criadas durante a execução e os objetos alocados dinamicamente ocupam regiões distintas dentro do mesmo espaço de endereços. Entender como essas três regiões se organizam dá ao programador uma imagem concreta de onde cada dado vive durante a execução.

flowchart TB
    classDef stack fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef heap  fill:#ede9fe,stroke:#7c3aed,color:#3b0764
    classDef data  fill:#d1fae5,stroke:#059669,color:#064e3b
    classDef code  fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
    classDef sep   fill:#f8fafc,stroke:#cbd5e1,color:#64748b

    TOP(["― endereços altos ―"]):::sep

    subgraph STACK["Pilha  ↓  cresce para baixo"]
        SF["frame: soma(a=3, b=4) — variáveis locais + endereço de retorno"]:::stack
        SM["frame: processar()"]:::stack
        SB["frame: main()"]:::stack
    end

    MID(["― espaço livre — pilha e heap crescem em direções opostas ―"]):::sep

    subgraph HEAP["Heap  ↑  cresce para cima"]
        H2["new ArrayList<>()"]:::heap
        H1["new String(...)"]:::heap
    end

    subgraph DATA["Dados estáticos"]
        D1["variáveis static e constantes"]:::data
    end

    subgraph CODE["Código"]
        C1["instruções de máquina — PC aponta aqui"]:::code
    end

    BOT(["― endereços baixos ―"]):::sep

    TOP --- STACK
    STACK --- MID
    MID --- HEAP
    HEAP --- DATA
    DATA --- CODE
    CODE --- BOT

A região de código contém as instruções de máquina produzidas pelo compilador. O tamanho dessa região é determinado em tempo de compilação e permanece fixo durante a execução. O PC percorre essa região instrução por instrução, avançando sequencialmente ou saltando para um novo endereço quando um desvio ocorre.

A pilha (stack) é a região onde o processador armazena o contexto de cada chamada de função ativa. Cada chamada de função cria um novo frame de pilha contendo as variáveis locais, os parâmetros recebidos e o endereço de retorno para onde a execução deve voltar após a função terminar. A pilha cresce em direção aos endereços baixos a cada nova chamada e recua quando a função retorna, descartando o frame correspondente. Esse mecanismo torna chamadas aninhadas e recursivas possíveis. Cada nível da recursão tem seu próprio frame com suas próprias variáveis, e o processador sempre sabe para onde retornar porque o endereço está gravado no frame. Uma pilha que cresce além da memória reservada para ela tenta acessar um endereço fora da região protegida que o sistema operacional mantém abaixo da pilha. O hardware levanta uma falha de página, o sistema operacional interpreta esse evento como stack overflow e encerra o processo.

O heap é a região de alocação dinâmica, onde vivem os objetos criados com new em Java. Diferente da pilha, cujo ciclo de vida está amarrado às chamadas de função, objetos no heap vivem pelo tempo que o programa determinar. O heap cresce em direção aos endereços altos, na direção oposta à pilha, e as duas regiões compartilham o espaço livre entre elas. Em Java, a gestão do heap é responsabilidade do garbage collector, que recupera a memória de objetos sem referências ativas. Os padrões de alocação no heap, seus custos e as situações em que ele se torna um gargalo merecem tratamento separado. O que importa aqui é que objetos em Java não vivem na pilha, e acessar um campo de objeto envolve seguir um ponteiro para o heap, uma operação cujo custo vai além do que o código-fonte sugere.

As três regiões operam em conjunto a cada instrução que o processador executa. O PC percorre o código. Cada chamada de função empurra um frame na pilha e cada retorno o remove. Referências a objetos no heap são ponteiros armazenados nos frames da pilha ou em outros objetos, e o hardware os resolve como leituras de memória cujo endereço é calculado em tempo de execução.

O ciclo de busca e execução

Com a memória endereçável, o PC indicando a próxima instrução e as instruções de máquina produzidas pelo compilador, é possível descrever o ciclo que o processador executa repetidamente para rodar um programa.

O ciclo começa quando o processador lê a instrução armazenada no endereço atual do PC e a transfere para um registrador interno, etapa chamada de busca (fetch). Em seguida, na decodificação (decode), ele interpreta os bits da instrução para identificar qual operação deve ser executada e quais operandos ela envolve. A execução (execute) processa a operação na unidade funcional correspondente, seja ela aritmética, de acesso à memória ou de controle de fluxo. Por último, na escrita (writeback), o resultado é gravado no registrador de destino ou no endereço de memória especificado. Com a escrita concluída, o processador incrementa o PC e o ciclo recomeça com a próxima instrução.

Instrução 1: |--FETCH--|--DECODE--|--EXECUTE--|--WRITEBACK--|
Instrução 2:                                               |--FETCH--|--DECODE--|--EXECUTE--|--WRITEBACK--|
Instrução 3:                                                                                             |--FETCH--|...

A representação acima mostra o modelo sequencial. Cada instrução precisa completar todas as quatro etapas antes que a instrução seguinte possa começar sua primeira etapa. Em termos de ciclos de clock, se cada etapa consome um ciclo, uma instrução leva quatro ciclos do início ao fim. Para executar três instruções, o processador gasta doze ciclos.

O desperdício inerente a esse modelo é quantificável. Durante a etapa de fetch da instrução 1, as unidades de decodificação, execução e escrita estão ociosas. Durante a etapa de decode, a unidade de busca está ociosa. Somente a unidade que executa o estágio atual do ciclo está em uso. Em um modelo com quatro etapas, três quartos das unidades funcionais ficam ociosas em qualquer ciclo específico. Esse número piora em processadores com etapas mais numerosas.

Os engenheiros que projetaram os primeiros processadores de alto desempenho nas décadas de 1950 e 1960 identificaram esse padrão e começaram a buscar formas de eliminar a ociosidade sem alterar o resultado correto da execução.

A pipeline como solução

A analogia com uma linha de montagem industrial torna a solução intuitiva. Em uma fábrica que monta quatro componentes em sequência, uma abordagem seria terminar completamente o primeiro produto antes de começar o segundo. Cada estação ficaria ociosa enquanto o produto estivesse em outra estação. Uma fábrica competitiva opera de forma diferente. Enquanto a estação 4 finaliza o produto A, a estação 3 já trabalha no produto B, a estação 2 no produto C e a estação 1 no produto D. O throughput quadruplica sem que nenhum produto individual seja fabricado mais rápido.

O mesmo princípio aplicado ao processador é a pipeline. Em vez de esperar que a instrução 1 complete todas as quatro etapas antes de começar a instrução 2, o processador inicia a busca da instrução 2 assim que a instrução 1 avança para decodificação. Quando a instrução 1 passa para execução, a instrução 2 está em decodificação e a instrução 3 já está em busca.

Ciclo:        1        2        3        4        5        6
Instrução 1: FETCH   DECODE  EXECUTE  WRITEBACK
Instrução 2:         FETCH   DECODE   EXECUTE  WRITEBACK
Instrução 3:                 FETCH    DECODE   EXECUTE  WRITEBACK

No modelo sequencial, três instruções consumiriam doze ciclos. No modelo com pipeline, as mesmas três instruções concluem em seis ciclos, com cada instrução ainda levando quatro ciclos do início ao fim. A velocidade de cada instrução individual não muda. O ganho de throughput vem da sobreposição, com mais instruções em andamento ao mesmo tempo, cada uma em um estágio diferente da pipeline.

Esse resultado não é meramente teórico. O CDC 6600, projetado por Seymour Cray e entregue em 1964 ao Lawrence Radiation Laboratory, foi o primeiro computador comercial a adotar sistematicamente essa lógica de múltiplas unidades funcionais sobrepostas. O sistema operava com dez unidades funcionais independentes, cobrindo operações de ponto flutuante (soma, multiplicação e divisão), aritmética inteira, deslocamentos, operações lógicas e controle de desvios. Enquanto uma unidade executava uma instrução, outras já processavam as instruções seguintes. O resultado foi um desempenho de pico de cerca de um megaflop, aproximadamente dez vezes superior aos sistemas que o antecederam. O IBM System/360 Model 91, anunciado em 1964 e com as primeiras unidades entregues em 1968, incorporou o algoritmo de Tomasulo para resolver dependências entre instruções e escalonar dinamicamente o trabalho entre as unidades funcionais, estabelecendo uma referência conceitual que processadores modernos ainda utilizam.

A pipeline resolveu a ociosidade das unidades funcionais, mas trouxe consigo dois tipos de problema que determinam em grande parte o desempenho observado em código.

Dependências de dados entre instruções consecutivas são a primeira fonte de impedimento. Se a segunda instrução usa um valor que a primeira ainda está calculando, a pipeline não pode avançar a segunda instrução para execução antes que o operando esteja disponível. O hardware precisa introduzir ciclos de espera, chamados de stalls, até que o valor apareça. Esses stalls surgem sempre que o compilador não consegue interpor instruções independentes entre duas instruções com dependência direta.

O custo dos desvios condicionais tem uma mecânica diferente. Quando a pipeline alcança um if ou um while compilado em código de máquina, ela não pode parar para aguardar a avaliação da condição. Cada ciclo parado significa throughput desperdiçado. Então ela continua buscando as instruções que seguem o desvio, apostando que serão as corretas. O problema acontece quando o resultado da condição, avaliado no estágio de execução, indica que as instruções buscadas eram as erradas. Tudo que foi buscado e parcialmente decodificado desde o desvio precisa ser descartado. Esse descarte é chamado de flush da pipeline. Em uma pipeline de quatro estágios, um flush desperdiça até três ciclos. Em pipelines mais profundas o custo cresce proporcionalmente. O Pentium 4 chegou a trinta e um estágios em algumas revisões, e sua penalidade por desvio mal previsto tornava o desempenho altamente sensível à quantidade de código condicional executado.

Os dois problemas, os hazards de dados e os hazards de controle, são os que determinam em grande parte onde o desempenho é ganho ou perdido no código. O mecanismo que processadores modernos desenvolveram para reduzir o custo dos desvios condicionais é a previsão de desvios (branch prediction), e é o ponto de partida do próximo artigo desta série. Junto a ele, o artigo examina como o compilador reorganiza instruções para minimizar stalls, como o processador executa trabalho fora de ordem para extrair paralelismo além do que o código sugere, e como a JVM atravessa esses mesmos desafios com uma camada adicional de complexidade.