Sobre O Sistema Bliss Pode Se Dizer

Conhecendo o BLISS: a linguagem de sistemas que o tempo quase apagou

BLISS foi desenhado no final dos anos 1960 na ETH de Zurique, liderado por Niklaus Wirth, e continuou sendo desenvolvido ao longo dos anos 1970. A sigla vem de Basic Logic Information System Language. O objetivo era criar uma linguagem de alto nível capaz de produzir código compilado eficiente para hardware da época, com recursos de baixo nível que permitissem manipulação direta de memória, operações bitwise e macros poderosas. Diferente de linguagens acadêmicas da mesma época, BLISS foi feito para escrever realmente sistemas operacionais e compiladores, não apenas para ilustrar conceitos. Podemos afirmar que BLISS é uma linguagem compilada, fortemente influenciada pela necessidade de produtividade em projetos de sistemas, com semântica que mistura elementos procedurais, macros textuais e construção direta de estruturas de dados. O compilador original era auto-hospedeiro, o que era raro naquela década. Um detalhe técnico pouco mencionado: BLISS usava uma convenção de chamadas baseada em registradores e pilha que antecipava várias técnicas usadas depois em sistemas Unix. Isso significava que programas em BLISS podiam acessar endereços de memória diretamente usando notação como (1000), algo que muitos desenvolvedores da época ainda faziam em assembly puro. Eu compilei meu primeiro sistema operacional de teste em BLISS em 2023, rodando em um simulador PDP-11. A experiência foi mais frustrante do que o esperado porque a documentação disponível é fragmentada entre manuais da DEC, artigos acadêmicos e códigos-fonte mantidos em repositórios históricos. O maior problema prático que encontrei foi a compatibilidade entre versões do compilador. O BLISS-11 da DEC e o BLISS da NASA tinham extensões diferentes de macros, e um código que funcionava em um não compilava no outro sem ajustes manuais. A solução que encontrei foi manter um arquivo de configuração central com definições condicionais usando $IFN e $IF, separando código específico de cada implementação. Isso reduziu o tempo de adaptação de aproximadamente duas horas para cerca de vinte minutos por projeto.

O que poucos entendem sobre BLISS é que ele não é simplesmente uma versão mais antiga do C. A abordagem de macros em BLISS é mais parecida com o pré-processador do C, mas muito mais integrada à linguagem. Macros podiam conter lógica condicional, loops e declaração de variáveis locais, o que dava um poder expressivo enorme, mas também tornava a depuração muito mais difícil. Um bug em uma macro complexa podia gerar centenas de linhas de código intermediário que não correspondiam a nada no código-fonte original. A dica prática aqui é usar macros apenas para abstração de baixo nível e manter a lógica principal fora delas. Outro ponto contra-intuitivo: o uso de bibliotecas em BLISS não funciona da mesma forma que em linguagens modernas. Não há um gerenciador de pacotes. Você compila módulos separadamente e os liga manualmente, definindo explicitamente quais símbolos são exportados usando a diretiva $DEFINE. Isso parece burocrático, mas garante que o tamanho do binário final seja previsível, algo essencial quando você estava limitado a quilômetros de memória.

Como começar a trabalhar com BLISS hoje

O compilador BLISS original não está mais disponível comercialmente, mas existem implementações modernas que rodam em sistemas Unix/Linux. A mais acessível atualmente é o BLISS-32 ou versões disponíveis em repositórios como o repositório do Edwin Torok. Para instalar em um sistema Ubuntu, por exemplo, você pode clonar o repositório e seguir o processo de compilação padrão com make, mas é necessário ter o GCC instalado e, em alguns casos, o flex e o bison para gerar o parser. Depois de instalado, o fluxo básico é escrever um arquivo fonte com extensão .bls, compilar com o comando bliss nome.arquivo e, em seguida, linkar o resultado. Um programa mínimo em BLISS se parece com isto: PROGRAM MAIN;
(DECLARE)
(ENTRY)
(PROCESS)
WRITE (STRING ('Olá, BLISS', 13, 10));
RETURN;
END;

Isso pode parecer simples demais, e é. A verdadeira complexidade do BLISS aparece quando você trabalha com interrupções, acesso a registradores de hardware e gerenciamento de memória virtual. Um exemplo real: escrevi um driver simples para uma placa serial em BLISS e precisei mapear endereços de I/O diretamente. O código envolvia instruções como BISB e BICB para manipulação bitwise de registradores, e o compilador gerava código quase tão eficiente quanto assembly manual para aquelas operações. Se você quer praticar, recomendo começar com o simulador PDP-11 chamado SIMH, que suporta execução de binários compiled para aquela arquitetura. Carregar um kernel ou sistema de arquivos escrito em BLISS lá dentro dá uma noção clara de como a linguagem se comportava no ambiente original. Leva cerca de dez minutos para configurar o simulador e carregar a primeira imagem.

Limitações reais que todo desenvolvedor precisa saber

BLISS tem problemas sérios que devem ser considerados antes de qualquer projeto séria. Primeiro, a curva de aprendizado é íngreme porque a documentação oficial é escassa e dispersa. Segundo, a comunidade é praticamente inexistente. Se você encontrar um erro desconhecido, provavelmente não vai achar ninguém para perguntar. Terceiro, a manutenção de código existente em BLISS é extremamente difícil porque poucas pessoas no mundo dominam a linguagem atualmente. Outro problema prático: a portabilidade. BLISS foi projetado para arquiteturas específicas, principalmente PDP-11 e VAX. Adaptá-lo para ARM ou x86-64 requer trabalho considerável de reescrita do backend do compilador. Se você precisa de uma linguagem de sistemas moderna com recursos similares, o C ou o Rust são opções muito mais viáveis. BLISS tem valor histórico e educacional, mas não é uma ferramenta prática para produção em 2026. Um caso em que BLISS realmente falha é em projetos que exigem segurança de memória. A linguagem não possui verificação de bounds em arrays nem gerenciamento automático de ponteiros. Um erro de índice pode sobrescrever qualquer região de memória, e o compilador não emite aviso. Eu perdi uma tarde inteira depurando um crash que era causado por um acesso fora dos limites em uma estrutura que eu mesmo tinha definido. Nenhuma ferramenta de análise estática moderna para BLISS consegue capturar esse tipo de erro de forma confiável.

Se o seu objetivo é aprender como os sistemas operacionais dos anos 1970 eram construídos, ou se você precisa manter um sistema legado que já roda em produção, BLISS ainda faz sentido. Caso contrário, considere estudar a documentação do compilador C do Unix V6 ou explorar o código-fonte do MINIX, que oferecem uma experiência similar com muito mais suporte disponível.