Compiladores vs Interpretadores

Um compilador traduz o programa-fonte por completo antes da primeira execução, gerando um artefato independente (código de máquina ou objeto). Um interpretador lê o fonte e o executa passo a passo, sem produzir esse artefato separado. A distinção fixa quando a tradução ocorre e afeta desempenho, detecção de erros e distribuição do programa.

A organização interna do compilador (léxico, sintaxe, semântica e o restante do pipeline) está em Fases do Compilador. Nesta página o assunto é só o modelo de execução: traduz-depois-roda versus interpreta-ao-correr.

Compilador

O compilador consome o texto-fonte e emite um executável que o sistema operacional pode rodar sozinho, sem o compilador presente.

Traduzir uma vez e reutilizar o binário evita repetir análise sintática e semântica a cada execução. Daí a vantagem de desempenho dos programas compilados. Na distribuição, basta enviar o artefato: quem roda não precisa da ferramenta de tradução.

Em C, o trecho

int main() {
    return 0;
}

vira programa.exe (ou equivalente). O sistema operacional dispara esse arquivo; o compilador já terminou o trabalho.

Interpretador

O interpretador analisa e executa o fonte no mesmo fluxo, em geral linha a linha ou bloco a bloco, sem gerar executável autônomo. Não há .exe intermediário: cada linha é lida e executada na hora. Quem roda precisa do interpretador instalado (ou embutido), porque não existe artefato separado para o sistema operacional executar sozinho.

O mesmo print(2 + 3) em Python não produz um binário para o SO: a ferramenta lê o comando, avalia a soma e imprime. Fechar o interpretador e “rodar de novo” é reler o fonte.

Linguagem e modelo de implementação são noções distintas. C costuma ser compilado e Python interpretado, mas isso é hábito de ferramenta — existe interpretador de C e existem compiladores de Python. Trabalhamos com o par $C$/$I$.

Por que dois modelos

A tradução de um programa $P$ não depende da entrada que $P$ vai processar: depende só do texto-fonte. O compilador congela esse trabalho num executável $E$ e, daí em diante, cada execução é só $E$ consumindo dados. O interpretador recusa esse congelamento: mistura tradução e execução, então cada corrida paga de novo o custo de entender o fonte — em troca de não exigir um passo de geração de binário e de poder começar a rodar assim que a primeira linha estiver pronta.

Por exemplo, o fonte print(2 + 3). No modelo compilado, a ferramenta lê o arquivo inteiro, gera um executável, e só então o sistema operacional roda esse arquivo: a tela mostra 5, e o compilador já saiu de cena. No modelo interpretado, a ferramenta lê print, avalia $2+3$, imprime 5 e termina — sem gerar arquivo executável no meio.

Compilar antes vs interpretar na hora

O compilador faz tradução antecipada (ahead-of-time): produz um binário que pode rodar muitas vezes sem nova tradução. O interpretador integra tradução e execução: o fonte é processado conforme a execução avança.

Programas compilados tendem a ser mais rápidos na execução; interpretados pagam o custo da tradução a cada trecho executado. Um laço que soma mil vezes ilustra a diferença: $C$ traduz o for uma vez e $E$ só acumula; $I$ reanalisa o corpo a cada volta. Implementações híbridas compilam trechos sob demanda: JIT (just-in-time) gera código nativo durante a execução, como em muitas VMs de Java e em motores JavaScript.

Formalização

Seja $P$ o programa fonte, $C$ o compilador e $I$ o interpretador. O compilador realiza a transformação:

onde $E$ é o programa executável. A execução subsequente é expressa por:

sendo $R$ o resultado do programa. No caso do interpretador, o processo é dado por:

onde a interpretação e execução ocorrem simultaneamente. Não confunda $C$ com $E$: $C$ é a ferramenta que produz o executável; $E$ é o que o sistema operacional dispara. No interpretador não há $E$ para nomear.

Lidas da esquerda para a direita, as setas deixam o invariante explícito: $C$ termina em $E$, e só então vem $R$; $I$ vai de $P$ a $R$ num único passo. O produto $E$ é o que permite distribuir e reexecutar sem levar $C$ junto.

O mesmo programa nos dois modelos

O fonte abaixo só soma e imprime. Serve para rastrear quando a tradução acontece, sem mudar o resultado $R$.

x = 2
y = 3
print(x + y)

Detecção de erros

Compiladores rejeitam erros de sintaxe e semântica na compilação, antes de rodar. Interpretadores só encontram muitos erros em tempo de execução, quando o fluxo alcança a linha problemática. A diferença está em quando o erro aparece.

int x = 1

if False:
    x = 1
print(x)

O que fica fora de $C$

$C: P \rightarrow E$ decide se o texto é um programa da linguagem e, se for, emite $E$. Três falhas não entram nessa decisão, porque não são propriedade do texto.

Erro de tempo de execução. A falha só existe quando $E$ já consome dados: índice além do fim do vetor, arquivo ausente, memória esgotada. $C$ já terminou; quem encontra o problema é a execução $E \xrightarrow{\text{execução}} R$.

Aritmética em valor dinâmico. A operação pode ser legal no texto e ainda assim falhar com os números daquela corrida. $C$ não substitui os operandos pelos dados de entrada: não divide, não testa zero, não simula estouro. O valor que ainda não está escrito em $P$ não é julgado na tradução.

Resultado errado em relação ao problema. $P$ compila, $E$ termina e produz $R$, mas $R$ não é a resposta que o problema pedia. Isso é erro de lógica. $C$ conhece a gramática e as regras estáticas da linguagem; não conhece o enunciado, então não compara $R$ com a resposta esperada.

O domínio de $C$ é o texto $P$, não o par (entrada, especificação). O mesmo vale para $I$ quanto à lógica: o interpretador também não compara $R$ com o enunciado, e uma divisão por zero só aparece se aquela corrida avaliar o operador.

Duas chamadas da mesma função separam a aritmética dinâmica do resultado errado:

int media(int a, int b) {
    return a / b;
}