O que é Arquitetura de Computadores

ISA, microarquitetura e organização

Quando falamos em "arquitetura de computadores", estamos usando um termo que carrega pelo menos três significados distintos. É fundamental separá-los logo no início, porque a confusão entre eles é uma das fontes mais comuns de mal-entendidos na área.

ISA (Instruction Set Architecture) — a arquitetura do conjunto de instruções — define o que o processador faz. É o contrato entre o hardware e o software: quais instruções existem, quais registradores estão disponíveis, como a memória é endereçada, quais tipos de dados são suportados. Exemplos de ISAs: x86-64, ARMv8, MIPS, RISC-V. Quando um compilador gera código de máquina, ele gera código para uma ISA específica.

Microarquitetura — define como o processador implementa a ISA. Dois processadores podem implementar a mesma ISA de formas completamente diferentes. O Intel Core i9 e o AMD Ryzen 9 executam o mesmo conjunto de instruções x86-64, mas têm microarquiteturas distintas — pipelines diferentes, caches de tamanhos diferentes, estratégias de predição de branch diferentes. A microarquitetura é invisível para o programador Assembly, mas determina a performance real.

Organização — refere-se à estrutura física e à interconexão dos componentes: quantos cores, como os barramentos conectam CPU, memória e dispositivos de E/S, qual a hierarquia de cache. A organização é a visão "de cima" de como os blocos se encaixam.

Conceito           O que define                 Exemplo
─────────────────  ───────────────────────────  ─────────────────────────
ISA                O que o processador faz       x86-64: ADD, MOV, JMP...
Microarquitetura   Como o processador faz        Zen 4 vs Golden Cove
Organização        Como os blocos se conectam    4 cores, 8MB L3, DDR5

Camadas de abstração

Um dos conceitos mais poderosos da ciência da computação é a abstração em camadas. Cada camada esconde a complexidade da camada abaixo e oferece uma interface simplificada para a camada acima. Em arquitetura de computadores, as camadas são:

┌─────────────────────────────────────┐
│  7. Aplicação                       │  ← o que o usuário vê
├─────────────────────────────────────┤
│  6. Linguagem de alto nível         │  ← C, Python, Java
├─────────────────────────────────────┤
│  5. Assembly / Linguagem de montagem│  ← ADD $t0, $t1, $t2
├─────────────────────────────────────┤
│  4. ISA (conjunto de instruções)    │  ← o contrato HW/SW
├─────────────────────────────────────┤
│  3. Microarquitetura                │  ← pipeline, cache, branch
├─────────────────────────────────────┤
│  2. Portas lógicas                  │  ← AND, OR, NOT, flip-flops
├─────────────────────────────────────┤
│  1. Transistores / Física           │  ← elétrons, semicondutores
└─────────────────────────────────────┘

Um programador Python não precisa saber como um transistor funciona para escrever um programa. Um projetista de circuitos não precisa saber Python. Cada camada abstrai a inferior. Mas — e este é o ponto central desta disciplina — entender as camadas abaixo da sua melhora drasticamente a qualidade do que você faz na sua camada.

Um engenheiro de software que entende como a cache funciona escreve código mais rápido. Um que entende o pipeline evita branch mispredictions desnecessárias. Um que entende a ISA consegue ler a saída do compilador e identificar ineficiências.

De C para Assembly: vendo a abstração em ação

Para tornar concreto o conceito de camadas, vejamos uma função simples em C e o que o compilador gera em Assembly MIPS a partir dela:

// soma.c — uma função trivial
int soma(int a, int b) {
    return a + b;
}

Compilando com mips-linux-gnu-gcc -S -O0 soma.c, o compilador gera algo como:

soma:
    addiu   $sp, $sp, -8      # reserva espaço na pilha
    sw      $fp, 4($sp)       # salva frame pointer
    move    $fp, $sp           # atualiza frame pointer
    sw      $a0, 0($fp)       # salva argumento a
    sw      $a1, 4($fp)       # salva argumento b (reuso do slot)
    lw      $t0, 0($fp)       # carrega a em $t0
    lw      $t1, 4($fp)       # carrega b em $t1
    add     $v0, $t0, $t1     # $v0 = a + b (resultado)
    move    $sp, $fp           # restaura stack pointer
    lw      $fp, 4($sp)       # restaura frame pointer
    addiu   $sp, $sp, 8       # libera espaço da pilha
    jr      $ra                # retorna para quem chamou

Uma linha de C (return a + b) virou mais de 10 instruções Assembly. Isso é a abstração funcionando: a linguagem de alto nível esconde toda a mecânica de manipulação da pilha, registradores e convenções de chamada. Ao longo deste curso, você vai aprender a ler e escrever Assembly, entender cada uma dessas instruções, e saber por que o compilador faz o que faz.

Lei de Moore e suas implicações

Em 1965, Gordon Moore observou que o número de transistores em um circuito integrado dobrava aproximadamente a cada dois anos. Essa observação — que virou quase uma profecia auto-realizável — guiou a indústria de semicondutores por mais de cinco décadas.

Ano     Processador          Transistores       Processo
──────  ───────────────────  ─────────────────  ─────────
1971    Intel 4004                   2.300       10 µm
1978    Intel 8086                  29.000       3 µm
1989    Intel 486                1.200.000       1 µm
1999    Pentium III             9.500.000       250 nm
2006    Core 2 Duo            291.000.000       65 nm
2012    Core i7-3770        1.400.000.000       22 nm
2020    Apple M1           16.000.000.000       5 nm
2024    Apple M4           28.000.000.000       3 nm

A Lei de Moore não é uma lei da física — é uma observação econômica e tecnológica. Ela está desacelerando: a redução do tamanho dos transistores encontra barreiras físicas (efeitos quânticos, dissipação de calor). A resposta da indústria tem sido buscar desempenho por outros caminhos: mais cores, instruções especializadas (SIMD, aceleradores de IA), arquiteturas heterogêneas (CPU + GPU + NPU), e chiplets (múltiplos dies em um pacote).

Para o engenheiro de software, a consequência prática é: o desempenho "grátis" acabou. Não basta esperar o próximo processador ser mais rápido. É preciso entender a arquitetura para escrever software que tire proveito do hardware moderno — paralelismo, localidade de cache, vetorização.

Métricas de desempenho

Como medimos se um processador é "rápido"? Depende do que estamos medindo. As métricas fundamentais em arquitetura de computadores são:

Frequência de clock (Hz) — quantos ciclos o processador executa por segundo. Um processador a 3 GHz executa 3 bilhões de ciclos por segundo. Mas frequência sozinha não diz nada sobre desempenho real — um ciclo pode fazer mais ou menos trabalho dependendo da microarquitetura.

CPI (Cycles Per Instruction) — quantos ciclos, em média, o processador leva para executar uma instrução. Um processador RISC típico pode ter CPI próximo de 1 (idealmente). Um processador com pipeline bem otimizado e execução fora de ordem pode ter CPI menor que 1 (múltiplas instruções por ciclo, ou IPC > 1).

Tempo de execução — a métrica mais honesta. O tempo que um programa leva para rodar do início ao fim. A equação fundamental de desempenho de Patterson & Hennessy é:

Tempo de CPU = Número de instruções × CPI × Período do clock

Ou equivalentemente:

Tempo de CPU = Número de instruções × CPI / Frequência do clock

Onde:
  Número de instruções → depende do programa e do compilador (ISA)
  CPI                  → depende da microarquitetura
  Frequência           → depende da tecnologia e do projeto do circuito

Exemplo:
  Programa com 10⁹ instruções, CPI = 1.5, clock = 3 GHz
  Tempo = 10⁹ × 1.5 / (3 × 10⁹) = 0.5 segundos

Throughput vs. latência — duas dimensões de desempenho que frequentemente entram em conflito:

• Latência: quanto tempo leva para completar uma tarefa (ex: tempo para executar uma instrução). Medida em segundos, milissegundos, ou ciclos.
• Throughput: quantas tarefas são completadas por unidade de tempo (ex: instruções por segundo, MIPS). Medido em operações/segundo.

Pipeline, por exemplo, aumenta o throughput (mais instruções terminam por ciclo) mas não reduz a latência de uma instrução individual — na verdade, pode até aumentá-la ligeiramente. Essa distinção aparece em todo lugar: bandwidth de rede vs. latência, IOPS de disco vs. tempo de acesso, requests por segundo vs. tempo de resposta.

No harness.os

A arquitetura em camadas que usamos em sistemas de computadores é a mesma que o harness.os aplica na engenharia de software: cada camada abstrai a complexidade da camada abaixo.

Camada no computador          Camada no harness.os
────────────────────────────  ────────────────────────────────────
Aplicação                     Interface do usuário (chat, CLI)
Linguagem de alto nível       Prompts e instruções em linguagem natural
Assembly / ISA                MCP tools (o "instruction set" do agente)
Microarquitetura              Implementação interna do agente (modelo,
                                context window, strategy)
Portas lógicas                Tokens, embeddings, attention heads
Transistores                  GPUs, TPUs, hardware de inferência

Assim como a ISA separa "o que" do "como" no hardware, os MCP tools separam "o que o agente pode fazer" de "como ele faz internamente". Um tool log_decision(title, rationale) é uma instrução — o agente não precisa saber como o banco de dados armazena a decisão, assim como o programador Assembly não precisa saber quantos transistores implementam a instrução ADD.

E a equação de desempenho tem paralelo direto: o "tempo de execução" de uma sessão depende do número de tool calls (instruções), da latência de cada call (CPI), e da velocidade do modelo (clock). Otimizar qualquer um dos três melhora o desempenho total.

Homework

1. Escreva uma função simples em C (ex: fatorial, Fibonacci) e compile com gcc -S -O0 para ver o Assembly gerado. Quantas instruções Assembly correspondem a cada linha de C? Agora compile com gcc -S -O2 e compare.
2. Pesquise o processador do seu computador ou celular. Identifique: qual é a ISA? Qual é a microarquitetura? Qual a frequência de clock? Quantos cores? É a mesma ISA que outro processador da mesma marca usa?
3. Use a equação de desempenho para comparar dois processadores hipotéticos: Processador A tem clock de 4 GHz e CPI de 1.5. Processador B tem clock de 3 GHz e CPI de 1.0. Para um programa com 10 bilhões de instruções, qual termina primeiro?
4. No harness.os, liste 3 MCP tools que você conhece e identifique a qual "instrução" cada um corresponde na analogia ISA. Qual é o equivalente do CPI para cada tool? (Dica: pense em latência de resposta.)

Resumo

• ISA define o que o processador faz; microarquitetura define como ele faz; organização é a visão de alto nível dos componentes
• Computadores são organizados em camadas de abstração: de transistores até aplicações, cada camada esconde a complexidade da inferior
• Uma linha de C pode gerar dezenas de instruções Assembly — a abstração esconde essa complexidade
• A Lei de Moore (transistores dobram a cada ~2 anos) guiou a indústria por 50+ anos mas está desacelerando
• A equação de desempenho: Tempo = Instruções x CPI / Frequência — três variáveis independentes
• Throughput (tarefas/tempo) e latência (tempo/tarefa) são métricas complementares que frequentemente conflitam
• MIPS como métrica é enganoso para comparar ISAs diferentes