5
Carregando publicação patrocinada...
5

Informações que acredito que sejam úteis:

1.

O projeto foi vibe-codado, conforme dá para ver aqui: https://github.com/PlummersSoftwareLLC/TinyRetroPad/blob/main/agents.md

2.

O dev commitou o executável: https://github.com/PlummersSoftwareLLC/TinyRetroPad/blob/main/trpad.exe

3.

O projeto peca em otimizações de tamanho óbvias, como neste trecho:

FindTail:
        mov     al, [esi]
        test    al, al
        je      GotTail
	
        cmp     al, '\'
        je      MarkTail
	
        inc     esi
        jmp     FindTail
        ...

Que poderia ter o tamanho reduzido drasticamente usando a instrução scasb com o prefixo repne.

Isso não é uma crítica ao autor do projeto. Escrever assembly é fácil, mas otimizar assembly (seja para tamanho, seja para performance) é outra história.

Mas esses erros de otimização óbvios servem para mostrar como ele conseguiria um código muito menor simplesmente escrevendo o projeto em C e compilando com flags de otimização para tamanho (-Os). O GCC não comete erros óbvios.

Ironicamente, escrever o código diretamente em assembly fez o código do projeto ficar maior.

4.

Em um projeto pequeno, a maior parte do tamanho do executável vem da própria estrutura do PE32/PE32+.

Se você compilar um hello world em C usando o MinGW, você provavelmente vai obter um executável com mais de 30 KB e vai pensar: "Ué, mas isso prova que escrever em C faria um executável muito maior que escrever em assembly".

Isso não é verdade, porque a maior parte do tamanho do executável vem de dados dentro dele que não são necessários para a execução do mesmo (como a seção .rsrc).

Dá para conseguir um executável funcional muito menor se você estruturá-lo manualmente ao invés de deixar o linker fazer isso. Eu até falei algo relacionado a isso neste post onde eu mostrei um hello world de 171 bytes de tamanho. Para comparação, um hello world normal tem 8.3KB de tamanho. Isso representa uma redução de quase 50x no tamanho do executável.

Isso, inclusive, reduziria muito mais o tamanho do executável do que a otimização do tamanho do código.

3

O simples que funciona! O povo quer entulhar IA em tudo, features não solicitadas etc.

Eu penso que poderia ter as features, mas como plugins opcionais. O gedit no Linux (Gnome), o Notepad++ para Windows fazem algo assim. Vários plugins para fazer bastante coisa.

Também o Kate e o KWrite no Linux (KDE), são dois editores, um mais simples e outro mais avançado. Quem só quer o básico, vai de básico. Quem quer mais avançado, vai no mais avançado.

1

Não querendo diminuir o trabalho dele, pois é algo incrível pelo tamanho de arquivo gerado, mas o bloco de notas antigo era um programa extremamente simples, hoje ele está muito bom e aceitando abas para múltiplos arquivos, salvamento em cache para arquivos não persistidos em disco, informações de contagem de caracteres e de linhas, permitindo visualização de formatação .md, (vou fingir demência e ignorar a adição do Copilot de forma voluntária) está bem parecido com os blocos de notas dos smartphones, ainda perde um pouco para as opções de Linux, pois estes ainda tem highlight para linguagens de programação.

Dito tudo isso, eu não me atrevería a fazer um projeto, por mais simples que seja, usando assembly, o cara foi monstro nessa!

1
0
-2

Eu vi o código-fonte. Uma aula de assembly e que ensina a muita gente como chamadas a API do Windows são feitas a partir do Assembly. Só que ele trapaceou com um packer, por isso conseguiu esse tamanho alardeado por aí. De toda forma, é uma boa fonte de estudo.