DEV Community: Lucas Wasilewski

Criando uma Runtime

Lucas Wasilewski — Fri, 25 Oct 2024 22:40:01 +0000

Olá, meu nome é Lucas Wasilewski e assim como coloquei na descrição do projeto no meu github desde que eu comecei a programar com o NodeJS (lá no início de 2021) eu sempre quis escrever algo que parecesse com a ferramenta, isso só aumentou depois que eu assisti o documentário sobre o projeto e fiquei de boca aberta em como o mundo open source pode ter várias reviravoltas e se mostrar muito acolhedor quando quer. E depois de uma semana de muita bateção de cabeça resolvi escrever esse artigo para que assim os futuros ~~loucos~~ programadores que quiserem esse desafio não cometam os mesmos erros que eu.

Runtimes de Javascript

Esse termo pode facilmente enganar qualquer pessoa que não entenda muito do assunto e então é preciso de uma boa definição:

Uma runtime de Javascript é uma ferramenta que permite executar a linguagem fora do navegador

Hoje em dia existem 3 runtimes populares: NodeJS, Deno (Node Killer) e o Bun (Deno Killer), mas elas basicamente fazem a mesma coisa: permitem você usar o javascript longe do navegador e usam de outras bibliotecas para criar funcionalidades novas, e isso é muito bom, uma vez que você pode usar qualquer uma delas para subir um servidor, criar bibliotecas e até mesmo aplicações mobile ou de terminal.

Ambos Node e Deno foram criados pela mesma pessoa: Ryan Dahl, e ele lá em 2009 criou a ferramenta para possibilitar que os desenvolvedores pudessem criar aplicações "async IO", ou seja, que não bloqueassem a thread principal mas ainda continuassem respondendo aos pedidos, com isso em mente ele criou a Libuv uma biblioteca que faz justamente isso. Até ai o projeto era apenas um grande amontoado de C e se ele quisesse mas pessoas usando a ferramenta ele precisava de alguma linguagem mais fácil de entender e usar, coincidentemente, nessa mesma época o Google lança a V8, que de um modo geral é um compilador ultra rápido de javascript, isso fez ele unir os dois e assim criar o Node.

Algum bom tempo depois (9 anos mais especificamente), Ryan saí do projeto e vai trabalhar em outras coisas que considerava mais interessante, isso fez ele perceber alguns vários erros que podiam ser corrigidos no Node, mas a comunidade já estava muito grande e ter que dar um grande passo para trás era impossível, então, determinado a fazer um trabalho melhor ele cria o Deno, outra runtime IO que promete ser muito superior ao Node, até a data de hoje (2024) o Deno está na versão 2.0 e está bem estável para projetos e comunidade.

Toda essa história fez mais pessoas entrarem na comunidade das runtimes e isso também nos levou a criação do Bun, e muito melhor, da minha e da sua runtime! Agora vamos ao que interessa.

Compilando a V8

Como dito anteriormente a V8 é o motor do Node, por isso vamos ter que realmente baixá-la e compilar manualmente para assim ter acesso as suas bibliotecas e headers. Por ser um projeto do Google eles tem os próprios métodos de baixar e compilar, então pra isso vamos ter que seguir o manual deles: link, apenas copiar e colar vai te levar ao comando finais.

Porém, aqui eu cometi um erro que demorou 3 dias para me tocar que estava fazendo tudo de errado. Após gerar os arquivos de configuração de build com:

tools/dev/v8gen.py x64.release

Você precisar tomar muito cuidado com o arquivo args.gn dentro da pasta out.gn/x64.release/ porque nele tem a configuração de build que o ninja (ferramenta de compilação) vai utilizar para gerar os arquivos da biblioteca, alguns tutoriais antigos usam o parâmetro v8_monolithic = true, mas nas versões recentes isso não é mais utilizado. De acordo com esse comentário do StackOverflow, nós precisamos agora usar o parâmetro is_component_build = true para gerar os arquivos certos e modificar as flags ao compilar o arquivo, algo muito bobo que se você não prestar atenção pode gastar um tempo precioso.

Após colocar o resto das flags corretamente, apenas precisamos rodar o comando para compilar o projeto

ninja -C out.gn/x64.release

Enquanto isso vá comer alguma coisa, porque a V8 é um projeto bem extenso e com inúmeros testes, dependendo da sua máquina esse processo pode facilmente levar 1 hora ou mais, então deixe rodando e continue lendo.

Cadê o console.log?

Após compilar você pode dar uma olhada no v8/samples/hello-world.cc e já começar a ter uma ideia de como compilar javascript, mas especificamente essas linhas:

v8::Local<v8::String> source =
          v8::String::NewFromUtf8Literal(isolate, "'Hello' + ', World!'");

// Compile the source code.
v8::Local<v8::Script> script =
          v8::Script::Compile(context, source).ToLocalChecked();

Vá em frente e dê uma brincada com a string que contêm o "Hello World", crie funções, loops, condicionais e se veja maluco ao perceber que se você incluir o clássico console.log() vai receber um undefined, isso primeiramente me deixou perplexo, eu sempre achei que o objeto console fazia parte da própria V8, mas na verdade quem o inclui é o próprio Node e os navegadores o incluem como parte do DOM (post de 2012 falando que o console.log provavelmente não é suportado pelos navegadores), ou seja, vamos ter que criá-lo nós mesmos.

Olá, Mundo!

Para conseguir criar nossas próprias funções primeiro precisamos entender que a V8 trabalha com vários escopos, um deles é o de contexto, onde é através dele que a runtime sabe onde e como executar o script de forma individual, dentro dele pode haver um objeto global que é compartilhado entre todos os outros, e é dentro dele que vamos inserir nossas funções customizadas.

v8::Local<v8::ObjectTemplate> global = v8::ObjectTemplate::New(GetIsolate());
global->Set(GetIsolate(), "print", v8::FunctionTemplate::New(GetIsolate(), this->Print));
v8::Local<v8::Context> context = v8::Context::New(GetIsolate(), nullptr, global);

Com essas linhas conseguimos criar um objeto que se chama global, inserimos um template de função "print" que ao ser executado chama a função Print.

static void Print(const v8::FunctionCallbackInfo<v8::Value>& info) {
      v8::HandleScope handle_scope(info.GetIsolate());
      for(int i = 0; i < info.Length(); i++) {
         if(i != 0) printf(" ");
         v8::String::Utf8Value str(info.GetIsolate(), info[i]);
         const char *c = ToCString(str);
         printf("%s", c);
      }
      printf("\n");
      fflush(stdout);
}

A função Print recebe esse parâmetro maluco que contém informações sobre a chamada da função dentro do javascript e é através dele que iteramos sobre todos os itens dentro dela, os transformamos em uma string C e printamos na tela, bem direta, bem simples e que cumpre com seu papel, isso já é o suficiente para colocar em um arquivo, lê-lo e jogar para a V8 (deixo essa em suas mãos).

// test.js
print("Olá, mundo!")

Libuv

Bom, espero que até aqui você esteja conseguindo acompanhar e até tenha parado de ler para fazer algumas implementações únicas para o seu Node caseiro, porém a V8 só vai nós levar até certo ponto, para conseguirmos chegar mais perto de uma runtime profissional precisamos fazer com que o javascript consiga realizar mais operações, para tal vamos utilizar da Libuv que foi criada justamente para isso.

Você pode achar o tutorial para instalar e compilar aqui. O importante a se notar aqui é que ela nos dá a liberdade de fazer operações assíncronas, ou seja, sem bloquear a thread principal, permitindo assim que o programa continue executando enquando faz um trabalha mais pesado (como abrir um arquivo ou esperar por requisições em um socket de servidor).

Ela mesma já vem embutido com a funcionalidade de criar um servidor http, então só precisamos sincronizá-la com as chamadas da V8. Não se engane, isso não é uma tarefa fácil, até porque a interface das duas bibliotecas se diferem bastante então é difícil conectar ambas, mas sempre há um jeito e o código fonte do node é aberto então certifique-se de roubar algumas ideias de lá

Conclusões

Chegamos ao final de mais um artigo e com eles vamos a alguns detalhes que eu percebi durante a implementação. A primeira com certeza é a complexidade, claro, não é um projeto simples, mas depois que você entender como interagir com a interface da V8 as coisas andam bem rápido.

Esse projeto me fez entender o Node muito melhor também. A questão que a runtime é apenas um conglomerado de bibliotecas se comunicando faz ser muito fácil entender como as coisas mais complexas (como o "event-loop") funcionam.

Caso você queira olhar o que eu fiz de certo, ou provavelmente de muito errado, por favor dê uma olhada no projeto pelo github: done

Talk is cheap, show me the code - Linus Torvalds

## Refêrencias

https://github.com/libuv/libuv
https://v8.dev/docs
https://stackoverflow.com/questions/71213580/cant-get-v8-monolith-to-genorate
https://github.com/ErickWendel/myownnode
https://github.com/WasixXD/done

20 milhões de linhas em 20s

Lucas Wasilewski — Wed, 09 Oct 2024 18:08:12 +0000

Olá, meu nome é Lucas Wasilewski e recentemente me propus a começar a programar com mais limitações, tanto no sentido de máquina quanto no sentido de programas auxiliares, dito isso, o ecossistema do JDK tem alguns gerenciadores de pacotes muito bem conhecidos como: Gradle e o Maven, porém, como você conecta uma das linguagens mais populares do mundo com um banco de dados sem eles? É isso que eu quis resolver.

JNI e libpq

Bem, como eu não tenho acesso a nenhuma outra biblioteca que faça a conexão ao Postgres, basta eu escrever uma eu mesmo?

Sim, e é bem mais fácil do que parece, o primeiro passo seria eu encontrar uma forma de me conectar ao banco através do Java, me veio a mente que em libs do NodeJs geralmente você especifica os dados necessários em um formato de string, mais ou menos assim:

postgres://usuario:senha@host:port/banco_de_dados

Então logo pensei que deveria ter algo haver com uma conexão de sockets e na verdade o projeto ia virar mais relacionado a redes. Porém, com uma rápida pesquisada na documentação do próprio PostgreSQL vi que eu iria primeiro ter que escrever um client e para isso eu precisava da biblioteca deles: libpq.

Lendo mais um pouco eu vi que só havia implementações em C e então o caminho estava mais claro do que nunca: eu só precisava de uma forma do Java conseguir chamar as funções de outra linguagem e resgatar os dados, isso tem um nome, se chama FFI (Foreign Function Interface) sendo algo muito utilizado devido as limitações das próprias linguagens. Um exemplo disso é o Numpy do Python que usa algumas partes em Fortran devido ao desempenho

Depois de mais uma pesquisada achei o JNI (Java Native Interface), que de acordo com a Oracle: JNI é uma interface que permite ao Java chamar código escrito em outras linguagens, como C ou C++. Basicamente o compilador do Java consegue gerar headers que podem ser depois implementados por essas linguagens usando o <jni.h>.

Claro que o meu objetivo desde o principio era somente conseguir fazer essa conexão e funções suficientes para um mísero CRUD, porém, a criação da lib foi muito rápida e eu queria mais desafios.

20 milhões de linhas

Saiu bem no inicio desse ano (2024) um desafio feito por Gunnar Morling em seu blog chamado de: One Billion Row Challenge, nesse desafio os participantes teriam que dar parse em um arquivo csv com 1 bilhão de linhas, tudo isso feito em Java, essa competição ficou bem famosa e a solução mais rápida foi em 1.5s, isso me deixou muito curioso. Afinal, o arquivo devia ser muito pesado e eles usaram muitos (realmente muitos) conceitos técnicos de memória, processador, sistema operacional e performance.

Um bilhão de linhas é muita coisa para mim ainda, mas talvez eu consiga trabalhar com um número um pouco menor, então após algumas sessões com a nossa LLM favorita criei um script em Python que conseguia criar dois arquivos csv com nome;email;telefone pesando 10mb e 1GB, com 209712 e 20971521 de linhas respectivamente. Agora só bastava por minha framework a maior prova de fogo que eu consegui criar.

Primeira implementação

O primeiro passo é ler o arquivo. Isso pode soar fácil se você estiver na casa das 200 mil linhas, a memória heap da JVM onde geralmente se guarda o conteúdo lido provavelmente suporta essa quantidade de dados, mas você nunca vai conseguir guardar 1 milhão de itens lá dentro. Por isso a sua melhor opção vai ser ler e processar linha a linha do arquivo, assim, você não estoura a memória e linearmente insere todos os itens. Bom, vamos aos testes, todos eles serão feitos em um i5-11400 com 12 threads.

Implementações	209.712 linhas	20.971.521 linhas
1°	9 minutos	Fim do universo

9 minutos.
Esse foi o melhor tempo que consegui com essa implementação e ainda nem chegamos na casa do milhão, o que deu errado? Não era pro Java ser rápido? Melhor reescrever tudo em React...

Segunda implementação

A nossa máquina está acostumada a fazer bilhões de instruções por minuto e o primeiro algoritmo apena lê sequencialmente e insere cada linha uma a uma no banco, ou seja, o tempo aumenta quanto mais linhas existem no arquivo, fora que estamos jogando um tempo de leitura precioso demais aguardando as outras tarefas de dar parse na linha e as de inserção.

Para reduzir esse problema podemos introduzir o multi-threading, fazendo com que usemos todos os nossos núcleos do processador e aumentando o número de "atores" para resolver o problema. Então nessa implementação adicionei uma queue, a thread principal lia o arquivo sequencialmente da forma mais rápida que podia e ia jogando em pedaços as linhas para que alguma outra thread pudesse puxar esse valor e fazer a inserção. Vamos aos testes:

Implementações	209.712 linhas	20.971.521 linhas
1°	9 minutos	Fim do universo
2°	4 minutos	Trava em 1.200.000

Opa, uma melhoria de 55,56%, já começou a ficar bem mais legal, até mesmo conseguimos processar o arquivo de 1Gb, porém, por algum motivo essa implementação fica presa nas 1.200.000 linhas.

Terceira implementação

Ok, as threads ajudam muito, mas, meu conhecimento em Java não é dos maiores, então eu usei um método que eu conhecia em outras linguagens: Eu pegava a linha inteira, usava o .split para separar por ; e então usava o .format para criar uma query de inserção, ao pesquisar por soluções melhores achei em um blog que o .format era o mais lento dentre todas as funções de string no Java e que isso era o que provavelmente estava causando essa enorme lentidão, então comecei a usar o StringBuilder:

StringBuilder sb = new StringBuilder();
sb.append("INSERT INTO users VALUES ");
for(String line : lines) {
    String[] split = line.split(";");
    sb.append("('"+ split[0] + "','" + split[1] +"'," + split[2]  +"),");
}
sb.setCharAt(sb.length() - 1, ';');
connection.query(sb.toString());

Nos testes isso realmente se provou ser um grande gargalo do algoritmo:

Implementações	209.712 linhas	20.971.521 linhas
1°	9 minutos	Fim do universo
2°	4 minutos	Trava em 1.200.000
3°	0,4 segundos	24 segundos

😲 essa foi minha reação quando eu fiz o primeiro teste, uma melhora de 99,83%. Tão rápido que eu mesmo não estava acreditando que no que estava acontecendo. Claro que o StringBuilder não foi a única solução adicionada, se você olhar com um pouco mais de atenção dá para perceber que junto todos os inserts das linhas e faço a query de uma vez só, assim reduzindo a quantidade de comandos realizados.

Um último suspiro

Eu ainda estava querendo mais, queria pelo menos algo em torno de 15 segundos (ia ficar bem no título, pensei comigo), então adicionei uma última carta na manga, as threadpools, elas são um número de threads que são criadas em conjunto e conseguem receber tarefas igualmente, assim reduzo o tempo de criação e também melhoro a forma de distribuir as tarefas:

Implementações	209.712 linhas	20.971.521 linhas
1°	9 minutos	Fim do universo
2°	4 minutos	Trava em 1.200.000
3°	0,4 segundos	24 segundos
4°	0,2 segundos	22-20 segundos

Aqui, começo a identificar os gargalos nas minhas implementações. Nessa última tentativa, além da pool de threads, utilizei outros métodos que encontrei para extrair o máximo de desempenho possível. Porém não consegui passar dos 20 segundos.

Conclusões

Esse projeto foi com certeza o mais técnico que fiz nos últimos tempos, apesar de não chegar no tempo que eu queria eu fiquei muito animado quando descobria cada nova forma de melhorar uma única linha (mesmo que eu provavelmente fosse ganhar no máximo 0.001 segundos).

Ainda sim fiquei pensando o quanto eu conseguiria extrair dessa única framework de 3 funções, vale ressaltar que no desafio do bilhão de linhas eles somente tinham que processar o arquivo e escrever na tela, assim, não levavam em conta o tempo de espera das querys (embora eu acredite que isso não seria um impedimento para eles).

Em conclusão, o meu pequeno desafio de ter mais impedimentos do que ajudas foi o pontapé para eu estudar e aprender mais sobre muita coisa que eu não conhecia, isso fora as que eu não quis entrar, como os métodos unsafe do java que iria me permitir mexer com ponteiros e endereços de memória.

Caso você queira olhar o que eu fiz de certo, ou provavelmente de muito errado, por favor dê uma olhada no projeto pelo github: Ant. Rumo aos 2 bilhões de linhas.

C is quirky, flawed, and an enormous success - Dennis Ritchie

Refêrencias

https://docs.oracle.com/javase/8/docs/technotes/guides/jni/

https://en.wikipedia.org/wiki/Foreign_function_interface

https://www.postgresql.org/docs/17/libpq.html

https://www.baeldung.com/java-read-lines-large-file

https://github.com/gunnarmorling/1brc

https://www.youtube.com/watch?v=EFXxXFHpS0M&t=1836s

Do it Yourself: CPU

Lucas Wasilewski — Mon, 29 Jul 2024 16:04:57 +0000

Olá, meu nome é Lucas Wasilewski e no último mês me deparei com esse vídeo, sinceramente fiquei tão empolgado com a ideia de poder criar uma "CPU" que coloquei esse projeto como prioridade na minha lista e algumas semanas depois aqui estamos. Esse artigo tem o objetivo de tentar te deixar muito animado ao ponto de você também desenvolver a sua própria CPU ou pelo menos um emulador dela.

CPUs

Antes de começar a sair pensando em como sua CPU vai parecer ou o nome dela, vamos dar um passo para trás e entender qual é o papel de uma e um pouco de sua história.

O ENIAC um dos primeiros computadores programáveis a serem construídos conseguia resolver uma grande quantidade de problemas, um deles sendo as distâncias que projéteis de artilharia podiam alcançar, sendo um grande benefício pro governo norte americano que tinha investido nisso na segunda guerra mundial.

Por mais que isso fosse uma revolução pra época, o ENIAC tinha uma desvantagem, cada programa tinha que ser construído do zero, ou seja, os programadores tinham que levar semanas para pensar no programa e plugar os cabos nos lugares certo (isso sem contar o tempo que levavam para corrigir bugs e outras coisas).

Para resolver esse problema de desenvolvimento foi criada a possibilidade de guardar o código na memória e da máquina ter instruções para interpretar esse programa, facilitando e permitindo uma melhor maneira de ser codificada.

John von Neumann foi o consultor de ambos ENIAC e seu sucessor o EDVAC, foi responsável também por construir a arquitetura de von Neumann que é de onde vem o nome da Central Processing Unit(CPU) nela todas os chips de aritmética, lógica e controle de IO ficam armazenados juntos e através de instruções ela consegue controlar o funcionamento do programa.

Atualmente, chamamos nossos processadores de CPU porque são projetados para realizar operações em velocidades absurdas. No entanto, se você, assim como eu, não tem uma mega corporação para minerar silício e criar placas com essa potência, a melhor alternativa será o nosso próximo tópico.

Emuladores

Emular uma CPU não é uma tarefa tão difícil quanto parece, apenas precisamos entender seu funcionamento básico e o resto é apenas programação.

O ciclo básico se dá por quatro passos:

Primeiro: Precisamos de um guia, ele vai quem vai indicar onde estamos e para onde vamos, vamos chamá-lo de PC ou program counter e então começamos a ler o programa
Segundo: Vamos buscar na memória a posição que o PC indica e carregá-la
Terceiro: Decodificaremos a instrução que foi carregada para localizar os valores que vamos utilizar para nossa operação
Quarto: Realizamos a instrução e incrementamos o PC.

Siga com esses passos até não encontrar mais nenhuma instrução e seu programa foi realizado.

Por mais que esse ciclo pareça bem simples, imagine que as CPUs modernas realizam essa operação a 3.5GHz, ou seja, a 3.5 bilhões por segundo. Comparando ao ENIAC que fazia 5.000(5kHz) operações matemáticas por segundo, isso é um aumento de 69,800% na velocidade de processamento, um número tão absurdo que hoje em dia um computador simular a outro é algo relativamente fácil.

Existem muitos artigos por aí ensinando como emular chips mais fracos como o: CHIP8 ou o muito respeitado 6502, que foi um dos microprocessadores que revolucionou áreas como a de desktop sendo a CPU principal do AppleII e do Comodore 64 ou a de Vídeo-Games integrando grandes consoles como o Nintendo Entertainment System(NES) e o Atari 2600.

Emular é algo mais do que apenas conseguir rodar jogos antigos e nostalgia, é sobre história, preservação e teimosia. Muitas pessoas gastaram dias, semanas e meses fazendo reverse engineering de instruções e mapeando cada componente daquele processador para que as pessoas pudessem entender como cada parte se comporta em determinada situações.

Agora chega de história e vamos começar a pensar em como emular a sua CPU.

Sua CPU

O Trabalho dela

Sua CPU vai ter vídeo? Essa é uma pergunta importante.

Várias CPUs antigas incluíam suporte a exibição gráfica, por isso contavam com partes da memória dedicadas para ter funções que fariam o display de vídeo mais fácil.

O CHIP8 por exemplo, especifica que os bitmaps das fontes ficassem nos primeiros 512 bytes da memória e tinha instruções próprias para desenhar pixels em uma tela de 64x32.

Fora isso, comece a imaginar os problemas que você quer que ela resolva, funções matemáticas como multiplicação, divisão, exponenciação ou radiciação podem ser essenciais se você queria resolver funções ou gerar estatística, porém, podem ser péssimos se você apenas queira simular o game of life.

Memória

Sua CPU provavelmente vai querer guardar o programa dela na memória para evitar que os programadores passem semanas colocando os cabos nos lugares corretos como no ENIAC. Para isso pense na memória como um array ou vetor na sua linguagem de programação preferida, armazenar algo nela pode ser algo tão simples quanto indicar que aquela posição terá aquele valor.

Registers

Um register é uma parte da memória de fácil acesso para a CPU, eles serão responsáveis por guardar valores que vão ser utilizados pelo seu programa ou por ela mesmo.

Como estamos emulando, não precisamos necessariamente colocá-los dentro da memória, em C por exemplo, eles podem ser campos de uma struct, isso irá facilitar em muito a sua vida

Suas instruções

De todas as partes arquiteturais essa é com certeza a mais divertida.

Op Codes

A CPU apenas entende binário. Isso é sua grande vantagem e desvantagem, por isso, iremos facilitar nosso entendimento criando mnemônicos que irão traduzir a linguagem humana para a linguagem de máquina. Então

MOV a, 1

Resulta em:

0001 0101 0001 0000 0000 0000 0000 0001

Sendo:

Os 8 primeiros bits o código binários para o comando MOV
Os próximos 8 bits para os registradores, nesse caso apenas o a foi usado, resultando no binário: 0001
E o últimos 16 bits sendo um valor decimal

Esse exemplo é da minha própria CPU e Assembler! Se você quiser ter um modelo de seguir ou ficou curioso, por favor cheque o projeto em https://github.com/WasixXD/Wasilewski

O número de bits que você reservar para a instrução também define a quantidade de comando disponíveis, ou seja, se reservar apenas 4 bits para as instruções o máximo de comandos que poderá ter será de 2⁴ ou seja 16.

Desafios que irá encontrar

Esse projeto não tem conceitos muito complicados, porém pode sair fora do controle muito rápido, então tome cuidados com os seguintes pontos:

Debuggar binário

Escrever binário na mão é muito difícil, considere antes de escrever a sua CPU escrever um Assembler que consiga gerar os binários corretos, isso vai economizar muito do seu tempo.

Testes

Testes são uma grande base para qualquer projeto, e nesse não é diferente, sempre cheque se sua CPU está realizando os comandos corretamente, e a vantagem é que você não precisa fazer os testes na mesma linguagem que você programou ela, eu por exemplo, fiz ambos CPU e Assembler em C, porém os testes unitários foram feitos em Python apenas pela facilidade.

Tipo de arquivo

Para carregar os programas escolha bem o tipo de arquivo, se optar por colocar os programas em um arquivo de texto vai ter que ler linha por linha, o que pode geral comportamentos não muitos preditivos já que esses arquivos podem conter espaços ou quebras de linhas.

Memória

De todas as operações as de memória são as mais difíceis, pois:

Não há certeza do que foi escrito no inicio do programa foi sobrescrito
O Endereço do que foi escrito pode ter sido perdido
O valor que quer ser armazenado na memória pode ser muito grande ou é diferente do que ela aceita.

Em dúvida consulte como as CPUs modernas lidam com esse problema.

E depois?

Se você conseguiu superar todas essas adversidades e sucedeu em criar sua CPU, parabéns!. Agora desenvolva em cima dela, corrija os erros, adicione coisas únicas, afinal é a sua CPU e nenhuma Intel ou AMD pode entrar no seu caminho para a supremacia.

Programming is the art of telling another human being what one wants the computer to do. Donald Knuth

Refêrencias

https://www.hp.com/ca-en/shop/offer.aspx?p=computer-history-all-about-the-eniac

https://www.columbia.edu/cu/computinghistory/eniac.html

https://en.wikipedia.org/wiki/ENIAC

https://research.swtch.com/6502

https://www.youtube.com/watch?v=7w8IeXKstJY&list=WL&index=19&t=824s

https://www.youtube.com/watch?v=Z5JC9Ve1sfI&t=338s

Bootloader 101

Lucas Wasilewski — Fri, 15 Mar 2024 21:10:52 +0000

Olá, meu nome é Lucas Wasilewski e nos últimos três meses eu fiquei obcecado com a matéria de Sistemas Operacionais. De como o computador liga até quando a área de trabalho do Windows aparece, eu queria saber tudo, vou dizer que "diversão" definitivamente não definiu esses meses mas o conhecimento que adquiri com certeza valeu a pena.

Por mais que estejamos na era da tecnologia, onde:

Os dados são o novo petróleo

Senti que tinha entrado em um mundo diferente, onde documentação é feita por gente que programa em papel e vivem em uma caverna, onde sua única fonte de luz é um terminal preto e branco. E os tutoriais? Poucos artigos na internet ensinando o básico de assembly e dizendo o quão ele é difícil. Meu objetivo nesse artigo é encorajar, percebi que por mais que seja um assunto muito empolgante (pelo menos para mim) a maioria dos artigos e documentações desencorajam logo no inicio ou tem uma complexidade muito alta para algo que deveria ser fácil, pois, se fosse difícil ou, pior ainda, impossível, não teríamos a quantidade de sistemas operacionais que temos por aí.

Como o computador Boota

Tudo começa quando você aperta o botão de ligar do seu computador, após o click é buscado algum programa que esteja na memória RAM, como não tem nenhum então é executado um firmware que já vem de fábrica, nós o conhecemos como: BIOS.

A primeira função da BIOS é realizar um procedimento chamado POST (Power On Self Test), onde se é feito um teste nos componentes conectados para detectar algum possível problema. Vale ressaltar que esse teste não é algo exclusivo de máquinas pessoais, se é usado em praticamente todos os sistemas embarcados.

Então a BIOS agora carrega na memória da máquina um executável que possa ser bootável, e para que isso ocorra é necessário ter dois fatores:

Ter 512 bytes
Ter um assinatura de boot

Os 512 bytes são para que o bootloader tenha pelo menos um pouco de espaço para trabalhar, já a assinatura de boot são dois bytes com valores mágicos que apenas indicam que aquele é realmente o bootloader.

A função do bootloader

O bootloader é nada mais que um programa que é executado pela BIOS, sua função é coletar e especificar algumas variáveis que vão ser usadas depois pelo kernel. Também podemos dizer que seu segundo objetivo é de trocar de Modo real para o Modo protegido ou até para o Modo Longo - Modo real (16 bits) é a forma no qual o seu computador liga, imagine que ele é apenas um estado que pode fazer poucas coisas, como fazer algumas chamadas para a BIOS e acesso a alguns periféricos, também pode usar pouca memória e tem pouca segurança, ou seja, queremos sair o mais rápido possível dele. Já o Modo protegido (32 bits) é o modo no qual já temos acesso a bem mais memória e podemos ter mais liberdade para desenvolver o que bem queremos.

Seu primeiro bootloader

Certo, chega de teoria, vamos botar a mão na massa, para essa parte você vai precisar de:

Um Assembler (NASM)
Um emulador (QEMU)

Verifique como instalá-los na sua distribuição Linux ou até mesmo no Windows.

Uma rápida introdução a Assembly

O assembly é uma linguagem de montagem de mais baixo nível que temos, ela é tão próxima do computador que se usa acrônimos para traduzir código hexadecimal/binário que geram os comandos, por exemplo:

; eax = 1
mov eax, 1

resulta em:

b8 01 00 00 00

Onde b8 é o opcode para mov, e 01 é o próprio 1.

PS: se alguém te perguntar essa é a sintaxe da Intel

Hello World

Agora que você já consegue entender um pouco de assembly, vamos criar um arquivo chamado boot.asm, no qual vamos escrever:

[org 0x7c00]
[bits 16]

jmp $ 

times 510 - ($ - $$) db 0
dw 0xaa55

Sim, parece bruxaria, mas vamos com calma ou melhor linha por linha.

[org 0x7c00]: Basicamente estamos querendo organizar a memória no qual estamos para começar a partir daquele endereço (0x7c00)
[bits 16]: Estamos dizendo para o nosso assembler que esse código irá rodar em um ambiente 16 bits (Modo real)
jmp $: Quase como um loop infinito, damos um jump para onde já estamos
times 510 - ($ - $$) db 0: Esse dá medo, mas a tradução seria, de onde estamos até o inicio do programa encha de 0s.
dw 0xaa55: define word define que os últimos 2 bytes do nosso programa contenham o número mágico (um número que a BIOS sabe que o arquivo é bootável)

Se você perceber nosso arquivo tem exatos 512 bytes de memória, ou seja estamos no limite. Para rodar basta compilar com:

$ nasm boot.asm -f bin -o boot.bin

e rodar usando:

qemu-system-x86_64 boot.bin

Mas, cadê o Hello World? Claro que esse programa apenas boota e faz com que a maquina fique em um estado "hibernado", não vai para frente nem para trás.
Para realmente escrevermos algo é um pouco mais complicado já que teremos que utilizar um interrupt, ou seja, vamos dizer a BIOS: "Quero escrever algo na tela" e a resposta dela é: "Ok, mas só se você já colocou tudo no lugar certo...".

[org 0x7c00]
[bits 16]


mov ah, 0x0e
mov al, 'H'
int 0x10
mov al, 'e'
int 0x10
mov al, 'l'
int 0x10
int 0x10
mov al, 'o'
int 0x10
mov al, 'W'
int 0x10
mov al, 'o'
int 0x10
mov al, 'r'
int 0x10
mov al, 'l'
int 0x10
mov al, 'd'

jmp $ 

times 510 - ($ - $$) db 0
dw 0xaa55

O que? você achou que teríamos algo chique como print? Não caro leitor, estamos no mais baixo nível possível (quase escrevendo em binário), nosso único companheiro é a BIOS e eu não confiaria muito nela. De qualquer forma, é claro que esse código pode ser melhorado e ficar menor, mas para motivos de aprendizado, acredito que dessa forma fique de melhor compreensão.

Vamos a explicação: Sempre que chamamos int 0x10, estamos invocando a BIOS para executar uma determinada função. Você pode estar se perguntando: qual função? A resposta é que existem várias funções que ela pode executar e o valor de ah é o que determina qual função queremos executar naquele momento, então, o valor 0x0e é o código para escrever o que está armazenado em al.

Parabéns! se você chegou até aqui você escreveu seu primeiro Bootloader, claro que ele não é algo muito complexo e apenas escreve HelloWorld na tela, mas esse é seu primeiro passo e ele é o mais importante que deve ser dado.

E depois?

Bem para realmente escrever um bootloader que seja útil teríamos bem mais trabalho, teríamos que definir em que parte da memória nosso Kernel estaria, conseguir algumas informações do disco rígido, definir variáveis globais como a GDT (Global Descriptor Table) e outros. É um tópico definitivamente extenso mas que vale a pena ser estudado, é algo que pode ser alcançado e com certeza deveria ser mais difundido, acredito que na famosa "Era da tecnologia" deveríamos ter mais opções de sistemas operacionais e mais concorrência.

Quem tem um bom porquê supera qualquer como.

Referências:
https://wiki.osdev.org/Expanded_Main_Page

https://blog.ghaiklor.com/2017/10/21/how-to-implement-your-own-hello-world-boot-loader/

https://github.com/ghaiklor/ghaiklor-os-gcc

https://www.baeldung.com/cs/computer-boot-process