ChrysaLisp
Return of the Dragon
O Chrysalisp é um sistema operacional de 64 bits, MIMD, multi-CPU, multi-thread, multi-núcleo e multiusuário com recursos como GUI, terminal, assembler OO, bibliotecas de classe, compilador de c-Script, intérprete Lisp, depurador, perfil, mecanismo de vetor e mais. Ele suporta MacOS, Windows e Linux para X64, Riscv64 e Arm64 e, eventualmente, se mudará para o metal nu. Ele também permite a modelagem de várias topologias de rede e o uso de Chrysalib Hub_Nodes para ingressar em redes host heterogêneas. Possui um conjunto de instruções da CPU virtual e um poderoso sistema e sistema de classe para o assembler e idiomas de alto nível. Possui ligação e carga dinâmica no nível da função e um terminal de comando com uma interface familiar para aplicativos de linha de comando no estilo de tubo. Um intérprete comum também é fornecido.
Junte-se a nós em #Chrysalisp-OS: Matrix.org para brincadeiras. Recomendado à Sala de Element.io.
Chrysalisp pode ser usado em macOS, Windows e Linux. Suporta CPUs X64, ARM64 e RISCV64. Ele também suporta um emulador de CPU de software VP64 usado para o processo de instalação, mas isso pode ser usado, com a opção -e , em plataformas em que nenhum suporte nativo da CPU sai atualmente, como o sistema de tempo de execução. Ele é executado em um ambiente hospedado enquanto a experimentação está sendo feita, mas eventualmente será transferida para correr em metal nu. No futuro, pretendo criar uma imagem de inicialização da VM para aparelhos unikernel e um alvo de montagem web para uso nos navegadores da Web.
O Chrysalisp permite a simulação de várias topologias de rede utilizando links ponto a ponto. Cada CPU na rede é representada como um processo de host separado, e os links ponto a ponto utilizam memória compartilhada para simular conexões bidirecionais de CPU para CPU. O design intencionalmente não inclui redes globais baseadas em ônibus.
O projeto Chrysalib, https://github.com/vygr/chrysalib, permite o uso de cabos IP e USB3/USB2 Prolific Chip "Copy" para criar redes host heterogêneas. Isso permite que os usuários conectem seus MacBooks, Linux, Windows Machines e PI4 para criar sua própria LAN de desenvolvimento ou redes WAN, o que é bem legal.
O Chrysalisp usa um conjunto de instruções virtuais da CPU para eliminar o uso de instruções nativas X64, ARM64, RISCV64 ou VP64. Atualmente, ele compila diretamente ao código nativo, mas tem a capacidade de também ser traduzido para o formulário de código de bytes e usar a tradução do tempo de execução.
Para evitar a necessidade de manipulação de registro para a passagem de parâmetros, todas as funções definem sua interface de registro e fontes e destinos de parâmetros são mapeados automaticamente usando um tipo topológico. Se os mapeamentos não-DAG forem detectados, o usuário poderá resolvê-los com um temporário. O software também inclui os operadores para facilitar a ligação de parâmetros a funções ligadas dinâmicas, endereços relativos, pools de string definidos automaticamente, referências e valores de quadros de pilha local. Os parâmetros de saída que não são usados podem ser ignorados com um sublinhado.
O Chrysalisp possui um objeto poderoso e sistema de classe que não se limita apenas ao assembler, mas é tão capaz quanto uma linguagem de alto nível. Ele permite a definição de classes estáticas ou classes virtuais com métodos embutidos, virtuais, finais, estáticos e de substituição. A GUI e o LISP são construídas usando este sistema de classe.
Possui ligação e carga dinâmica no nível da função. As funções são carregadas e vinculadas à demanda à medida que as tarefas são criadas e distribuídas. Atualmente, as funções são carregadas no sistema de arquivos da CPU, onde a tarefa está localizada, mas no futuro eles virão do objeto do servidor com o qual a tarefa foi criada e será transportada pela rede, conforme necessário. As funções são compartilhadas entre todas as tarefas que usam o mesmo objeto de servidor; portanto, apenas uma cópia de uma função é carregada, independentemente de quantas tarefas a usam.
As funções do sistema são acessadas através de um conjunto de classes estáticas, o que facilita o uso e elimina a necessidade de lembrar os locais de funções estáticas e também dissociar a fonte das alterações no nível do sistema. As definições de interface para essas funções podem ser encontradas nos arquivos sys/xxx.inc .
Um terminal de comando com uma interface familiar para aplicativos de linha de comando de estilo de tubo é fornecido com o vetor args, stdin, stdout, stderr etc. classes para facilitar a construção de mestres e escravos de tubos, com aninhamento arbitrário de tubos de linha de comando. Embora essa não seja a melhor maneira de criar aplicativos paralelos, é muito útil para a composição das ferramentas e oculta toda a mensagem que passa por trás de uma API familiar baseada em fluxos.
Um intérprete comum como Lisp é fornecido. Isso está disponível na linha de comando, através do comando lisp . Para construir todo o tipo de sistema (make) , calcula a carga de trabalho mínima de compilação ou (make-all) para fazer tudo, independentemente do prompt de comando LISP. Este LISP possui uma capacidade de 'snippets' C-Script para permitir a mistura de expressões compiladas de c-Script dentro do código de chamada de atribuição e função. Existe um passe de otimização elementar para essas expressões. Tanto o compilador de assembler virtual quanto o C-Script estão escritos no LISP, procure no lib/asm/code.inc , lib/asm/xxx.inc.inc , lib/asm/func.inc , lib/trans/x86_644.inc , lib/trans/arm64.inc e lib/asm/vp.inc sobre como isso é feito. Algumas das primitivas Lisp são construídas por meio de um script de inicialização de que cada instância de uma classe Lisp é executada na construção, consulte Class/Lisp/Root.inc para obter detalhes. O ambiente de compilação e criação, juntamente com todos os comandos de compilação e fabricação, são criados através da ferramenta Lisp Command Line no LIB/ASM/ASM.inc , novamente este automático é executado para cada instância do comando lisp executado do terminal. Você pode estendê -lo com qualquer número de arquivos adicionais, basta colocá -los após o comando LISP e eles serão executados após o arquivo LIB/ASM/ASM.inc e antes do processamento do STDIN.
Não tenha a ideia de que, devido a ser codificado em Lisp interpretado, o assembler e o compilador serão lentos. Uma construção do sistema totalmente limpa da fonte, incluindo a criação de um arquivo de imagem de inicialização pré-limitado, recursivo, assume a ordem de 2 segundos em um MacBook Pro 2014! Ciclo de dev (make) e (remake) abaixo de 0,5 segundos. Não é lento!
As tabelas de roteamento de link de rede são criadas na inicialização de um link e o processo é distribuído na natureza, cada link inicia um preenchimento de inundação que acaba atingindo todas as CPUs e, ao longo do caminho, marcou todas as rotas de uma CPU para outra. Todas as rotas mais curtas são encontradas, as mensagens que saem da CPU são atribuídas a um link à medida que o link se torna gratuito e vários links podem e executam mensagens em rotas paralelas simultaneamente. Mensagens grandes são divididas em fragmentos menores ao enviar e reconstruídos no destino para maximizar o uso das rotas disponíveis.
A opção -run Command Line inicia tarefas para inicializar essa CPU, como a GUI experimental (um trabalho em andamento, -run gui/gui/gui.lisp ). Você pode alterar o script de lançamento de rede para executar mais de uma sessão da GUI, se quiser, tente iniciar a GUI em mais de que a CPU 0, procure no Funcs.sh na função boot_cpu_gui ! :)
A opção -l de linha de comando cria um link, atualmente até 1000 CPUs são permitidas, mas é fácil de ajustar. Os arquivos de link de memória compartilhada são criados na pasta TMP /TMP , portanto, por exemplo , /TMP /000-001 seria o arquivo de link para o link entre a CPU 000 e 001.
Um exemplo de rede visualizado com PS se parece com isso para uma rede de malha 4x4:
./main_gui -l 011-015 -l 003-015 -l 014-015 -l 012-015
./main_gui -l 010-014 -l 002-014 -l 013-014 -l 014-015
./main_gui -l 009-013 -l 001-013 -l 012-013 -l 013-014
./main_gui -l 008-012 -l 000-012 -l 012-015 -l 012-013
./main_gui -l 007-011 -l 011-015 -l 010-011 -l 008-011
./main_gui -l 006-010 -l 010-014 -l 009-010 -l 010-011
./main_gui -l 005-009 -l 009-013 -l 008-009 -l 009-010
./main_gui -l 004-008 -l 008-012 -l 008-011 -l 008-009
./main_gui -l 003-007 -l 007-011 -l 006-007 -l 004-007
./main_gui -l 002-006 -l 006-010 -l 005-006 -l 006-007
./main_gui -l 001-005 -l 005-009 -l 004-005 -l 005-006
./main_gui -l 000-004 -l 004-008 -l 004-007 -l 004-005
./main_gui -l 003-015 -l 003-007 -l 002-003 -l 000-003
./main_gui -l 002-014 -l 002-006 -l 001-002 -l 002-003
./main_gui -l 001-013 -l 001-005 -l 000-001 -l 001-002
./main_gui -l 000-012 -l 000-004 -l 000-003 -l 000-001 -run gui/gui
Dê uma olhada no docs/intro.md para obter instruções para começar em todas as plataformas suportadas.
A GUI experimental exige que a biblioteca SDL2 seja instalada.
Pegue -os através do seu gerenciador de pacotes, no Linux com:
sudo apt-get install libsdl2-dev
Ou no Mac via Homebrew.
brew install sdl2
Dê uma olhada no docs/intro/intro.md para instruções específicas da plataforma. O seguinte é para sistemas OSX e Linux. O Windows possui um main.exe pré-criado, ou você pode configurar o Visual Studio para compilar as coisas, se desejar.
Na primeira vez que você baixar Chrysalisp, você terá apenas a imagem de inicialização do emulador VP64. Você deve criar as imagens de inicialização nativa na primeira vez. Isso é um pouco mais lento que as botas e o sistema subsequente, mas nos permite manter o arquivo instantâneo.zip o mais pequeno possível.
Se no Linux ou Mac via Homebrew:
make install
Ou no Windows
install.bat
make
./run_tui.sh [-n num_cpus] [-e] [-b base_cpu]
Interface do usuário de texto Rede totalmente conectada. Cada CPU possui links para todas as outras CPU. Cuidado com isso, pois você pode acabar com um número muito grande de arquivos de link e regiões de memória compartilhada. A CPU 0 inicia um terminal para o sistema host.
./run.sh [-n num_cpus] [-e] [-b base_cpu]
Rede totalmente conectada. Cada CPU possui links para todas as outras CPU. Cuidado com isso, pois você pode acabar com um número muito grande de arquivos de link e regiões de memória compartilhada. A CPU 0 lança uma GUI.
./run_star.sh [-n num_cpus] [-e] [-b base_cpu]
Rede conectada de estrelas. Cada CPU tem um link para a primeira CPU. A CPU 0 lança uma GUI.
./run_ring.sh [-n num_cpus] [-e] [-b base_cpu]
Rede de anel conectado. Cada CPU possui links para os CPUs seguintes e anteriores. A CPU 0 lança uma GUI.
./run_tree.sh [-n num_cpus] [-e] [-b base_cpu]
Rede conectada à árvore. Cada CPU possui links para sua CPU pai e até dois CPUs de crianças. A CPU 0 lança uma GUI.
./run_mesh.sh [-n num_cpus on a side] [-e] [-b base_cpu]
Rede conectada de malha. Cada CPU possui links para 4 CPUs adjacentes. Isso é semelhante às malhas do transputador. A CPU 0 lança uma GUI.
./run_cube.sh [-n num_cpus on a side] [-e] [-b base_cpu]
Rede conectada ao cubo. Cada CPU possui links para 6 CPUs adjacentes. Isso é semelhante às malhas TMS320C40. A CPU 0 lança uma GUI.
Pare com:
./stop.sh
Instantâneo com:
make snapshot
Isso criará um arquivo instantâneo.zip do diretório OBJ/ contendo apenas as estruturas do diretório host, o Windows Main_Gui.EXE pré-compilado e main_tui.exe mais os arquivos vp64 boot_image !
Usado para criar o instantâneo mais compacto.zip que sobe no GitHub. Isso deve vir após a criação de (make-all-platforms) Boot_Image Set!
obj/vp64/VP64/sys/boot_image
obj/x86_64/WIN64/Windows/main_gui.exe
obj/x86_64/WIN64/Windows/main_tui.exe
Limpo com:
make clean
