Assembly Linguagem

Por que ainda alguém iria escrever em assembly linguagem hoje?

A resposta curta é: raramente. A maioria dos programadores nunca escreveu uma linha em assembly de propósito. Rode um profiler, encontre o gargalo, otimize aquela função crítica e pronto. Mas quando eu precisava fazer isso, era sempre porque algo muito específico tinha explodido e ninguém mais sabia o que estava acontecendo. Ao longo dos anos, a coisa mudou pouco na prática. Você ainda precisa entender registers, stacks, calling conventions, flags do processador e como o compilador decide transformar seu código C em instruções. O restante é debugging e paciência.

Como baixar as ferramentas certas para começar

Se você quer mexer com assembly linguagem de verdade, pare de procurar tutoriais genéricos e comece escolhendo uma arquitetura. A mais documentada e acessível é x86_64 no Linux. O que você vai precisar: nasm ou gas (gcc) para montar o código. No Debian/Ubuntu é só um apt install nasm gcc gdb. No Arch, pacman -S nasm gcc gdb. No macOS, brew install nasm binutils e use gcc com flags específicas porque o macOS usa AT&T por padrão e tem restrições de execução no stack.

Para o Windows, você tem o MASM (Microsoft Macro Assembler) que vem com o Visual Studio, ou pode usar o nasm + wine se preferir sintaxe Intel, mas aí depende de como o linker do Windows lida com os objetos. Recomendo evitar o Windows se for aprender. A stack de depuração é infinitamente melhor no Linux.

A sintaxe importa mais do que você imagina

Existem duas sintaxes principais que vão definir como você vai sofrer. A sintaxe Intel, que parece com mov eax, [ebx], é a mais usada em documentações e tutoriais. A sintaxe AT&T, que inverte a direção e usa prefixos, aparece como movl (%ebx), %eax. O gas usa AT&T por padrão; o nasm usa Intel. Misturar as duas é a forma mais rápida de perder horas debuggando algo que na verdade é só erro de notação. Quando eu comecei, escrevi um programa inteiro em Intel e tentei montar com gas. O erro era em tudo. Levei duas horas entendendo que não era bug no código, era a diferença entre mov dest, src e mov src, dest. A partir daí, nunca mais misturei.

Escrevendo seu primeiro programa funcional

Vamos ao básico que funciona. Um programa minimalista que imprime "Oi" e sai com código zero no Linux x86_64, usando syscalls diretamente:

.section .data
msg: .ascii "Oi\n"
len = . - msg

.section .text
.global _start

_start:
    mov $1, %rax          syscall write
    mov $1, %rdi          stdout
    mov $msg, %rsi        buffer
    mov $len, %rdx        tamanho
    syscall

    mov $60, %rax         syscall exit
    xor %rdi, %rdi        status 0
    syscall

Monta com nasm -f elf64 hello.asm, liga com ld hello.o -o hello e roda. Se funcionar, você acabou de pular a barreira mais difícil: o toolchain.

O problema que ninguém te conta sobre calling conventions

Compiladores usam a convenção System V AMD64 ABI no Linux. Os primeiros seis argumentos inteiros vão em rdi, rsi, rdx, rcx, r8, r9. rax guarda o valor de retorno. rbx, rbp, r12-r15 são callee-saved — quem chama não espera que você os altere sem restaurar. rax, rcx, rdx, rsi, rdi, r8-r11 são caller-saved, ou seja, podem ser destrudos a qualquer momento. O erro clássico é escrever uma função em assembly que modifica rbp sem restaurar. O chamador vai cair numa corrupção de stack que só aparece segundos depois, em outro lugar completamente diferente do código que você escreveu. Vá de frame pointer explicitamente e restaure tudo no final. Sempre.

Um caso real que me lembro: em 2019, estava otimizando uma função de hash de strings que chamava uma sub-rotina em assembly dentro de uma thread pool. A sub-rotina não salvava r12 antes de usar. Funcionou perfeitamente em testes unitários. Na produção, sob carga, o r12 tinha o ponteiro para o próximo job da thread pool. O resultado era uma corrupção silenciosa que fazia a aplicação processar jobs errados. A correção foi adicionar push %r12 / pop %r12 na entrada e saída da função. Duas instruções. Doze horas de investigação.

Quando usar e quando fugir

Assembly linguagem ainda tem seu lugar em três categorias principais. Primeira: kernel space, drivers, bootloaders e coisas que precisam rodar antes do compilador C existir. Segunda: hot paths em motores de jogo, compressão, criptografia, onde cada ciclo conta. Terceira: segurança e reverse engineering, onde você precisa ler o que o compilador gerou para entender o que está acontecendo. Para o resto, não use. Compiladores modernos como GCC e Clang com -O3 e -march=native geram código competitivo na grande maioria dos casos. Escrever assembly manualmente raramente supera o que o compilador faz, a menos que você conheça as particularidades da arquitetura alvo — cache lines, branch prediction, pipeline stalls — e consiga fazer algo que o otimizador não consegue inferir.

O caso em que eu desisti de manter assembly em produção foi um projetor de ray tracing onde tínhamos rotinas SIMD manuais. Funcionavam bem no Skylake, mas quebraram no EPYC da AMD porque as instruções AVX2 tinham comportamento diferente com vetores sobrepostos. Migrei para intrinsics e o código ficou portável sem perda real de performance. Levei três semanas para reescrever tudo. Perdi dois dias debuggando diferenças de alinhamento de memória que o compilador automaticamente resolvesse.

O que aprender antes de escrever uma linha

Antes de ir fundo, tenha noção de pelo menos três coisas. Linguagem C para entender como structs, ponteiros e arrays se traduzem em endereços. Arquitetura x86_64 básica — registers, memória, stack. Depuração com gdb e objdump. Sem isso, você vai passar meses achando que o problema está no assembly quando na verdade é um erro de casting em C que fez o ponteiro apontar pro lugar errado.

Recursos práticos

O System V ABI é a Bíblia. Leia as seções sobre calling conventions e stack layout. O site Intel Intrinsics Guide é útil se for trabalhar com SIMD, mas isso é passo seguinte. Para aprender assembly puro, o livro "Programming from the Ground Up" do Jonathan Bartlett é gratuito e direto. O tutorial do OSDev Wiki cobre desde boot até syscalls.

Limitações reais que ninguém anuncia

Assembly linguagem não é solução mágica. O código é extremamente frágil a mudanças de arquitetura. O que roda rápido no AMD Ryzen pode rodar devagar no Intel por causa de diferenças no scheduler. Portabilidade é praticamente inexistente. Manutenção é cara. E o tempo que você gasta escrevendo e testando raramente se paga, exceto nas categorias que citei acima. Se o seu objetivo é aprendizado, vale a pena. Se é performance em produção, investigue profiling primeiro, depois considere intrinsics, depois, só então, assembly manual. Na ordem inversa, você vai gastar semanas em algo que um -march=native resolveria em cinco minutos.