ymawky - servidor web feito diretamente em assembly ARM64

• ymawky é um servidor web de arquivos estáticos escrito apenas em assembly ARM64, funcionando sem libc e usando somente syscalls, com uma arquitetura que faz fork para cada conexão
• O alvo de desenvolvimento é o macOS, e a execução só é possível em Apple silicon arm64; para compilar, são necessários Xcode Command Line Tools e make
• A execução padrão começa em 127.0.0.1:8080; é possível especificar a porta, mas atualmente endereços personalizados não são suportados, e ele funciona apenas em 127.0.0.1
• A raiz de documentos é www/ por padrão; GET / procura por www/index.html, e as páginas de erro são fornecidas a partir de err/(code).html
• Os métodos HTTP suportados são GET, PUT, DELETE, OPTIONS, HEAD; execução de código no lado do servidor ou parsing avançado de URL como /search?query=term não são suportados
• PUT suporta por padrão uploads de até 1GiB, escrevendo primeiro no arquivo temporário www/.ymawky_tmp_<pid> e depois usando rename para evitar que uploads parciais sobrescrevam arquivos existentes
• GET suporta requisições Range: bytes=, lidando com os formatos bytes=X-N, bytes=-N, bytes=X-, e diz oferecer bom suporte a navegação em vídeo
• Detecta o tipo MIME com base na extensão do arquivo e envia o cabeçalho de resposta Content-Type, reconhecendo muitas extensões de arquivos web, imagens, fontes, documentos, vídeos, áudios e arquivos compactados
• Como proteções de caminho, rejeita caminhos acima de PATH_MAX, bloqueia escape de caminho baseado em .., aplica o prefixo www/ a todos os caminhos de requisição e rejeita caminhos com symlink usando O_NOFOLLOW_ANY
• Para mitigar DoS do tipo slowloris, fecha a conexão e retorna 408 Request Timeout se o intervalo entre leituras passar de 10 segundos ou se o recebimento completo dos headers ultrapassar 10 segundos
• Requisições HTTP/1.1 exigem o header Host:; embora o valor de Host não seja realmente usado, a presença do header é obrigatória conforme a RFC 9112 Seção 3.2
• Em config.S, é possível ajustar a raiz de documentos, o diretório de páginas de erro, o arquivo padrão, o timeout de recebimento, os limites de velocidade e tamanho de PUT, o número máximo de processos simultâneos etc.
• Para portar para Linux ou outro Unix, seria necessário modificar registradores de chamadas de syscall e svc, forma de retorno de erro, fork(), SO_NOSIGPIPE, O_NOFOLLOW_ANY, renameatx_np(), layout de structs, sintaxe de relocação Mach-O, signal handling etc.

[GN⁺]

Comentários do Hacker News

• Quando você realmente escreve programas grandes em assembly, especialmente com um macro assembler, percebe rápido que isso não é fundamentalmente diferente de programação de alto nível, só mais verboso
  No fim, basta se acostumar a criar abstrações com procedimentos e macros, e muitas vezes ler assembly de forma eficaz é bem mais difícil do que escrevê-lo

  • Fazendo este trabalho, percebi a mesma coisa. É preciso escrever de forma muito mais explícita, mas o jeito como cada função funciona em si não é fundamentalmente diferente
    strlen, seja em C, Rust, Assembly ou qualquer outra linguagem, no fim percorre a string procurando o byte NULL. Como você escreve exatamente o que a CPU deve fazer e em que ordem, às vezes isso até parece mais intuitivo do que em outras linguagens

• É um projeto realmente bonito e muito bem feito. Seguindo a linha dos outros comentários, esse tipo de projeto me lembra mais um mapa de Minecraft
  Existem mapas enormes e impressionantes, mapas pequenos de sobrevivência, mapas abertos localmente só para mim e meus amigos, e servidores comerciais buscando grande escala. Graças à IA, ficou muito fácil construir casas no servidor ou projetar novas estradas, mas o valor criado nesse mundo depende do propósito original do servidor e de fazer sentido ou não continuar adicionando casas e estradas
  É ótimo que servidores comerciais possam crescer mais rápido e ter mais casas e ruas, mas o afeto que um projeto artístico gera é incomparável

• Ainda dá uma sensação reconfortante saber que alguém ainda tenta fazer esse tipo de coisa na mão. Eu não era o único

  • Fiquei obcecado com essa ideia por um tempo, acabei começando e mergulhei totalmente nisso por algumas semanas
    Se houver projetos parecidos, eu adoraria ver, e fico feliz por não ser só eu. Acho que, se a maioria dos programadores estudasse assembly por algumas semanas ou meses, muito do ar de mistério sobre como CPU e linguagens compiladas funcionam desapareceria

• Projeto divertido. Eu tenho uma versão muito mais minimalista para x86 Linux, e se quiser ver como ela é, está aqui: https://github.com/jcalvinowens/asmhttpd

  • Uau, esse projeto realmente foi uma grande inspiração para mim. Li há algum tempo e fiquei muito impressionado
    Queria saber se tudo bem eu adicionar o link do seu repositório no meu README

• Aquela falsa capa de livro da O'Reilly é simplesmente fantástica

  • Aquele livro foi exatamente o motivo que me levou a fazer isso. O subtítulo do livro acabou gerando a sigla do nome do projeto

• Mesmo sendo uma comparação meio sem sentido, fiquei curioso sobre o nível de desempenho em comparação com servidores web completos. Queria ver métricas como o máximo de requisições por segundo

  • Sinceramente, ainda não fiz benchmark, mas acho que o ymawky seria bem mais lento do que a maioria dos servidores web completos
    O ymawky usa fork por conexão, então é fundamentalmente mais lento do que a abordagem usada por servidores de produção como nginx ou Apache. O nginx usa E/S orientada a eventos com kqueue/epoll, o que permite lidar com milhares de conexões simultâneas sem o overhead de criar um processo para cada requisição. O Apache usa pool de threads para atender várias conexões sem criar uma nova a cada vez
    Uma comparação direta com outros servidores web acabaria medindo principalmente a diferença entre fork por conexão e loop de eventos/pool de threads, e não teria muito a ver com assembly
    Se comparasse com um servidor parecido, também com fork por conexão, mas escrito em C, acho que a vazão seria quase a mesma. O gargalo desse modelo não é o código em si, e sim o próprio fork(). O impacto provavelmente seria maior no tamanho do binário e no tempo de inicialização do que nas requisições por segundo. Ainda assim, seria divertido medir de verdade

• Ficou muito bom. Também estou trabalhando em um projeto parecido, mas menor, em RISC-V, e isto ficou excelente

  • Muito legal. Se estiver publicado em algum lugar, eu adoraria ver

• Quero deliberadamente ir contra a direção para a qual esse mundo de vibe coding está indo e sentir que estou sendo desafiado de novo, então estou pensando em escrever um renderizador de software em WebAssembly
  Não sei se vou conseguir terminar, é uma loucura, e não dá para dizer que seja útil. Mesmo assim, a sensação é ótima
  Parabéns ao autor original pela conquista

  • Eu fiz exatamente a mesma coisa e foi muito divertido. Não era para colocar algo novo no mundo, era só um desafio prazeroso para mim mesmo
    Depois de terminar, estou fazendo um jogo com isso, mas como a graça do desafio já passou, esse lado não está avançando muito. Tudo bem, porque foi divertido. Se eu tivesse feito com vibe coding, não teria tido essa diversão nem essa satisfação
  • Você está falando de um renderizador de software 3D? Aprendi muito fazendo esse tipo de coisa em x86 e C na adolescência e no começo da carreira
    Fiquei curioso para ver quão bem um LLM escreveria um renderizador para CGA em assembly 8088 puro, então pedi um. Ele produziu um demo bem decente logo de cara. No prompt, eu tinha colocado os vetores das naves de Elite
    https://imgur.com/a/Dy5rUku

• Um dos meus primeiros projetos em assembly foi um script CGI escrito 100% em assembly x86
  Um servidor web completo é claramente mais impressionante. Mesmo assim, para iniciantes eu recomendaria primeiro procurar sobre CGI do Apache e mod_cgi

  • Uau, sinceramente, acho que escrever scripts CGI em assembly me assustaria mais do que escrever o servidor em assembly
    Tenho pensado em suporte a CGI há algumas semanas, mas ainda não mergulhei de verdade nisso. Se estiver hospedado em algum lugar, eu adoraria ver, parece que seria um ótimo material de referência quando eu for mexer nisso depois

• Estamos migrando para IA, deixando de escrever código e quebrar a cabeça com isso, e aqui temos alguém escrevendo um servidor web em assembly
  Dá uma bela dose de humildade

  • Dá mesmo uma dose de humildade. Está bem claro qual dos caminhos eu prefiro
  • Quem é “nós” aqui? Eu não tenho tão pouca autoestima a ponto de entregar código gerado por máquina e malfeito em vez de fazer meu trabalho direito