Mel posicionava cada instrução para encontrar a cabeça de leitura do tambor — e vencia o montador

No ensaio USENET de Ed Nather de 1983, 'The Story of Mel, a Real Programmer', Mel é o programador da Royal McBee Computer Corp., fabricante do LGP-30 e do mais novo RPC-4000 — máquinas baratas de memória de tambor. Mel, que desaprovava compiladores ('Se um programa não consegue reescrever o próprio código, de que serve?'), havia escrito em hexadecimal puro o programa mais popular da empresa: um jogo de blackjack que lotava o estande do LGP-30 em todas as feiras de informática, enquanto os vendedores da IBM ficavam por ali conversando entre si.

O ofício de Mel era o timing. Numa máquina de tambor, o código só roda rápido se cada instrução chega à cabeça de leitura exatamente quando a anterior termina. Existia um montador otimizador para isso, mas Mel o recusava porque seus posicionamentos eram imprevisíveis e forçariam constantes separadas. Conhecendo o valor numérico de cada código de operação e atribuindo seus próprios endereços de tambor, ele podia tratar qualquer instrução como uma constante numérica — pegar uma instrução de soma anterior e multiplicar por ela.

Ele escrevia primeiro os corpos dos laços mais internos para que reivindicassem as posições ótimas do tambor, e colocava atrasos deliberados logo após a cabeça de leitura para que consumissem uma revolução completa — o 'mais péssimo'. Nather comparou os programas otimizados à mão de Mel com o mesmo código passado pelo montador otimizador: 'os de Mel sempre rodavam mais rápido'. O ensaio termina com um Pedido de Mudança no qual o pessoal de vendas queria um switch de mudança para permitir que os clientes ganhassem no blackjack.

Mel relutou diante da desonestidade, depois cedeu — mas escreveu o teste ao contrário, de modo que o switch fazia a máquina trapacear e ganhar sempre. Ele declarou que seu subconsciente era incontrolavelmente ético e recusou-se a corrigir, e o ensaio de Nather transformou o episódio em um dos textos folclóricos da computação mais reimpressos.

Escrever primeiro os laços mais internos e posicionar cada instrução para encontrar a cabeça de leitura exatamente no tempo certo — usando os valores numéricos dos opcodes como constantes para código automodificável.

A latência do tambor fazia do posicionamento das instruções a diferença entre código rápido e glacial.

O montador otimizador otimizava o posicionamento, mas destruía o controle do programador sobre ele.

Escrever primeiro os laços mais internos permitia que o código mais quente reivindicasse os melhores endereços antes de qualquer outra coisa.

O código automodificável por meio da aritmética de opcode-como-constante eliminava por completo as constantes separadas.

A otimização real explora a física da máquina, não a cadeia de ferramentas: quem conhece o valor numérico de cada opcode pode transformar constantes em código e timing em material de projeto.

O ensaio tornou-se um dos textos folclóricos da computação mais reimpressos, e 'não exatamente ótimo' entrou no vocabulário dos programadores por meio da cunhagem de Mel, 'mais péssimo'; o RPC-4000 e a própria Royal McBee desapareceram há muito tempo, lembrados principalmente por esta história.