Com 12.590 bytes, a versão simplificada da máquina virtual (VM) de Adele está rodando no Arduino UNO. A expectativa é manter a memória RAM livre em torno de 1.500 bytes que, em tese, serão suficientes para os programas que rodarão em Milton.
A parte inferior da imagem exibe a pilha da VM, um dos recursos mais legais da linguagem. Quando elaborei o conceito de Adele, tinha em mente computadores antigos (386s), o que me obrigou a fazer escolhas minimalistas para o uso de memória, flexibilizar a implementação de instruções (API em C) e otimizar o máximo possível a execução.
Por sorte ou coincidência, o conceito se saiu bem no Arduino e seu teto de 2kb de memória RAM. Obviamente precisarei decidir como resolver os demais gargalos:
- Ponto flutuante: na versão para PCs, a pilha de Adele usa floats. Os AVRs não são muito eficientes em operações com esse tipo de dados, então a primeira versão da pilha utiliza inteiros. Preciso estudar como é a situação nos Esp8266 e Esp32.
- Imagens: os editores milton:p e milton:u são bastante econômicos no uso de memória (16×16 pixels por sprite), mas na prática ainda terei o dilema de lidar com múltiplos framebuffers de 8×5 para saída de TV ou 20×15 para saída VGA via Esp8266. Penso em reduzir os sprites na TV para 8×8, se for possível, subindo o framebuffer para 16×10.
- Laços e saltos: Adele é linguagem de montagem, de forma que o controle do programa é feito por repete (laços), vaipara, vaisemenor, vaisemaior (condicionais) e executa (funções do usuário). Na versão PC, mantenho uma pilha do mesmo tamanho da principal para controlar a recursão. Nesta implementação, a pilha já aloca preciosos 128 bytes.
- Variáveis: penso em substituí-las integralmente por 16 registradores de 8 bits e 16 de 32 bits. Nos PCs, são 256 inteiros, 256 em ponto flutuante e 256 para acesso a strings (ostentação). Não imagino o usuário comum programando em Adele e sim em abstrações mais amigáveis que gerem o bytecode que a máquina interpreta (detalharei o formato em breve). Sendo assim, como as variáveis serão resolvidas na camada da VM fará pouca diferença.
Sobre o último ponto, realmente penso em manter Lua (lua.vm.js) e Blocky como opções para o usuário construir programas em Milton. Precisarei apenas oferecer interfaces para comunicação com a VM e as funções disponíveis (pretendo implementar todas).
Finalmente, o próximo passo consistirá em preparar editores de código em Adele Assembly para o servidor web e para as saídas gráficas TV/VGA. Depois disso será possível começar a falar em Milton como computador pessoal.
O funcionamento da VM resolve a parte mais irritante de desenvolver para AVRs – carregar o sketch novamente para cada caractere alterado. Poderei trabalhar diretamente na IDE web ou até no editor gráfico, seja com arquivos, seja no prompt interativo de comando. Assim como no NodeMCU, haverá um script de boot para Milton que será carregado automaticamente, se existir no sistema de arquivos.
