Categorias
Atualizações

Milton #11

Interpretador e máquina virtual “Adele VM-e” funcionais no Arduino UNO

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.

Categorias
Atualizações

Milton #2

O dispositivo precisará de visor embutido para que o estudante consiga realizar configurações básicas no primeiro uso: configuração de Wi-fi, ajuda para conexão com TVs e monitores VGA, pareamento de dispositivos bluetooth e assim por diante.

O display de LCD 16×2 é ótimo para testar questões rápidas de entrada e saída, porém inadequado para exibir informações gráficas ou assistentes de configuração mais longos. Comecei a investigar alternativas gráficas de tamanho reduzido e custo acessível – baita desafio. Tenho a impressão que telas são a parte mais cara de tudo, talvez mais que conectividade.

Comparação entre o display e uma bateria 9V. Mínimo!
Comparação entre o display e uma bateria 9V. Mínimo!

Superado o receio de queimar os controladores, comecei a construir os testes com meu Arduino Uno R3 e o display LCD colorido de 1.3 polegadas, 240×240 pixels. Apesar da imagem linda, o bicho é mínimo e muito caro (R$ 30-40 no Brasil, R$ 8-12 na China).