ChrysaLisp
Return of the Dragon
Chrysalisp est un système d'exploitation parallèle multi-CPU, MIMD, multi-CPU, multi-thread, multi-core et multi-utilisateurs avec des caractéristiques telles qu'un interprètes GUI, un terminal, un assembleur OO, des bibliothèques de classe, un compilateur C-Script, un interprète LISP, un débogueur, un profil, un génie de la police vectorielle, et plus encore. Il prend en charge MacOS, Windows et Linux pour X64, RISCV64 et ARM64 et finira par se déplacer vers le métal nu. Il permet également la modélisation de diverses topologies de réseau et l'utilisation de Chrysalib Hub_Nodes pour rejoindre des réseaux hôte hétérogènes. Il a un ensemble d'instructions CPU virtuel et un système et un système de classe puissant pour les langages de l'assembleur et de haut niveau. Il a une liaison et un chargement dynamiques au niveau de la fonction et un terminal de commande avec une interface familière pour les applications de ligne de commande de style tuyau. Un interprète de type LISP commun est également fourni.
Rejoignez-nous chez # Chrysalisp-OS: Matrix.org pour les plaisanteries. élément.io salle recommandée.
Chrysalisp peut être utilisé sur macOS, Windows et Linux. Prend en charge les processeurs X64, ARM64 et RISCV64. Il prend également en charge un émulateur de processeur du logiciel VP64 utilisé pour le processus d'installation, mais cela peut être utilisé, avec l'option -e , sur les plates-formes où aucun support CPU natif ne sort actuellement, comme système d'exécution. Il fonctionne sur un environnement hébergé pendant que l'expérimentation est en cours, mais finalement il sera transféré pour fonctionner sur du métal nu. À l'avenir, je prévois de créer une image de démarrage VM pour les appareils Unikernel et une cible WebAssembly à utiliser dans les navigateurs Web.
Chrysalisp permet la simulation de diverses topologies de réseau en utilisant des liaisons point à point. Chaque processeur du réseau est représenté comme un processus hôte distinct et les liens point à point utilisent la mémoire partagée pour simuler les connexions CPU-CPU, bidirectionnelles. La conception n'inclut pas intentionnellement le réseau mondial en bus.
Le projet Chrysalib, https://github.com/vygr/chrysalib, permet d'utiliser des câbles IP et USB3 / USB2 prolifiques "copier" pour créer des réseaux hôtes hétérogènes. Cela permet aux utilisateurs de connecter leurs MacBooks, Linux, Windows Machines et PI4 pour créer leurs propres réseaux LAN ou WAN de développement, ce qui est assez cool.
Chrysalisp utilise un ensemble d'instructions CPU virtuel pour éliminer l'utilisation des instructions natives X64, ARM64, RISCV64 ou VP64. Actuellement, il se compile directement avec le code natif, mais il a la capacité d'être également traduit par le formulaire de code d'octets et d'utiliser la traduction d'exécution.
Pour éviter le besoin de jonglerie de registre pour le passage des paramètres, toutes les fonctions définissent leur interface de registre et les sources et destinations de paramètres sont automatiquement cartographiés à l'aide d'un type topologique. Si des mappages non-dags sont détectés, l'utilisateur peut y remédier avec un temporaire. Le logiciel comprend également des opérateurs pour faciliter la liaison des paramètres aux fonctions liées dynamiques, des adresses relatives, des pools de chaînes, des références et des valeurs de trame de pile locales. Les paramètres de sortie qui ne sont pas utilisés peuvent être ignorés avec un soulignement.
Chrysalisp possède un puissant objet et un système de classe qui ne se limite pas à l'assembleur mais qui est tout aussi capable qu'un langage de haut niveau. Il permet la définition de classes statiques ou de classes virtuelles avec des méthodes en ligne, virtuelles, finales, statiques et de remplacement. L'interface graphique et le LISP sont construits à l'aide de ce système de classe.
Il a une liaison et un chargement dynamiques au niveau de la fonction. Les fonctions sont chargées et liées à la demande lorsque des tâches sont créées et distribuées. Actuellement, les fonctions sont chargées à partir du système de fichiers CPU où se trouve la tâche, mais à l'avenir, ils proviendront de l'objet serveur avec lequel la tâche a été créée et sera transportée sur le réseau selon les besoins. Les fonctions sont partagées entre toutes les tâches qui utilisent le même objet serveur, donc une seule copie d'une fonction est chargée, quel que soit le nombre de tâches l'utiliser.
Les fonctions du système sont accessibles via un ensemble de classes statiques, ce qui facilite l'utilisation et élimine la nécessité de se souvenir des emplacements de fonction statiques, et de découpler la source des modifications au niveau du système. Les définitions d'interface de ces fonctions peuvent être trouvées dans les fichiers sys / xxx.inc .
Un terminal de commande avec une interface familière pour les applications de ligne de commande de style de tuyau est fourni avec des classes ARGS Vector, Stdin, Stdout, Stderr, etc. pour la construction facile de tuyaux et d'esclaves, avec nidification arbitraire des tuyaux de ligne de commande. Bien que ce ne soit pas le meilleur moyen de créer des applications parallèles, il est très utile pour la composition des outils et cache tous les messages passant derrière une API basée sur des flux familiers.
Un interprète LISP commun est fourni. Ceci est disponible à partir de la ligne de commande, via la commande lisp . Pour construire l'intégralité du type de système (make) , calcule la charge de travail minimum de compilation, ou (make-all) pour tout faire malgré tout, à l'invite de commande LISP. Ce LISP a une capacité C-Script 'Snippets' pour permettre le mélange d'expressions compilées C-Script dans le code d'appel d'attribution et de fonction. Un pass d'optimisation élémentaire existe pour ces expressions. L'assembleur virtuel et le compilateur C-Script sont écrits dans LISP, regardez dans le lib / asm / code.inc , lib / asm / xxx.inc , lib / asm / func.inc , lib / trans / x86_64.inc , lib / trans / arm64.inc et lib / asm / vp.inc pour la façon dont cela est fait. Certaines des primitives Lisp sont construites via un script de démarrage que chaque instance d'une classe LISP s'exécute sur la construction, voir Class / Lisp / Root.inc pour plus de détails. L'environnement de compilation et de fabrication, ainsi que toutes les commandes de compilation et de fabrication, sont créés via l'outil de ligne de commande LISP dans lib / asm / asm.inc , encore une fois, cette auto s'exécute pour chaque instance de la commande lisp exécutée à partir du terminal. Vous pouvez prolonger cela avec n'importe quel nombre de fichiers supplémentaires, il suffit de les placer après la commande LISP et ils s'exécuteront après le fichier lib / asm / asm.inc et avant le traitement de STDIN.
N'obtenez pas l'idée qu'en raison d'être codé dans un lisp interprété, l'assembleur et le compilateur seront lents. Un système entièrement nettoyé construit à partir de la source, y compris la création d'un fichier d'image de démarrage récursif complet récursif, prend l'ordre de 2 secondes sur un MacBook Pro 2014! Dev Cycle (make) et (remake) en moins de 0,5 seconde. Ce n'est pas lent!
Les tables de routage des liens réseau sont créés pour démarrer un lien, et le processus est distribué dans la nature, chaque lien commence un remplissage d'inondation qui atteint finalement tous les processeurs et en cours de route a marqué tous les itinéraires d'un processeur à un autre. Tous les itinéraires les plus courts sont trouvés, les messages qui sortaient du processeur sont affectés à un lien car le lien devient gratuit et que plusieurs liens peuvent et effectuer des messages parallèles sur des itinéraires parallèles simultanément. Les grands messages sont divisés en fragments plus petits lors de l'envoi et reconstruit à destination pour maximiser l'utilisation des itinéraires disponibles.
L'option -run de la ligne de commande lance des tâches sur le démarrage de ce processeur, telles que l'interface graphique expérimentale (un travail en cours, -run gui/gui/gui.lisp ). Vous pouvez modifier le script de lancement du réseau pour exécuter plus d'une session GUI Si vous le souhaitez, essayez de lancer l'interface graphique sur plus que CPU 0, regardez dans funcs.sh à la fonction boot_cpu_gui ! :)
L'option de ligne de commande -l crée un lien, actuellement jusqu'à 1000 CPU sont autorisés, mais c'est facile à ajuster. Les fichiers de liaison de mémoire partagés sont créés dans le dossier TMP / TMP , donc par exemple / TMP / 000-001 serait le fichier de liaison pour le lien entre CPU 000 et 001.
Un exemple de réseau visualisé avec PS ressemble à ceci pour un réseau de maillage 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
Jetez un œil aux docs/intro.md pour les instructions pour commencer toutes les plates-formes prises en charge.
L'interface graphique expérimentale nécessite l'installation de la bibliothèque SDL2 .
Obtenez-les via votre gestionnaire de packages, sur Linux avec:
sudo apt-get install libsdl2-dev
Ou sur Mac via Homebrew.
brew install sdl2
Jetez un œil aux docs/intro/intro.md pour des instructions spécifiques à la plate-forme. Ce qui suit est pour les systèmes OSX et Linux. Windows a un Main.exe pré-construit fourni, ou vous pouvez configurer Visual Studio pour compiler les choses vous-même si vous le souhaitez.
La première fois que vous téléchargez Chrysalisp, vous n'aurez que l'image de démarrage de l'émulateur VP64. Vous devez créer les images de démarrage natives la première fois. Ceci est un peu plus lent que les bottes et les compléments de système ultérieurs, mais nous permet de garder le fichier snapshot.zip aussi petit que possible.
Si sur Linux ou Mac via Homebrew:
make install
Ou sous Windows
install.bat
make
./run_tui.sh [-n num_cpus] [-e] [-b base_cpu]
Interface utilisateur de texte basée sur le réseau entièrement connecté. Chaque CPU a des liens vers tous les autres processeurs. Attention à cela, car vous pouvez vous retrouver avec un très grand nombre de fichiers de liaison et de régions de mémoire partagées. CPU 0 lance un terminal au système hôte.
./run.sh [-n num_cpus] [-e] [-b base_cpu]
Réseau entièrement connecté. Chaque CPU a des liens vers tous les autres processeurs. Attention à cela, car vous pouvez vous retrouver avec un très grand nombre de fichiers de liaison et de régions de mémoire partagées. CPU 0 lance une interface graphique.
./run_star.sh [-n num_cpus] [-e] [-b base_cpu]
Réseau connecté Star. Chaque CPU a un lien vers le premier CPU. CPU 0 lance une interface graphique.
./run_ring.sh [-n num_cpus] [-e] [-b base_cpu]
Réseau connecté à la bague. Chaque CPU a des liens vers les CPU suivants et précédents. CPU 0 lance une interface graphique.
./run_tree.sh [-n num_cpus] [-e] [-b base_cpu]
Réseau connecté d'arbre. Chaque processeur a des liens vers son processeur parent et jusqu'à deux processeurs enfants. CPU 0 lance une interface graphique.
./run_mesh.sh [-n num_cpus on a side] [-e] [-b base_cpu]
Réseau connecté en maillage. Chaque CPU a des liens vers 4 CPU adjacents. Ceci est similaire aux maillages du transputer. CPU 0 lance une interface graphique.
./run_cube.sh [-n num_cpus on a side] [-e] [-b base_cpu]
Réseau connecté en cube. Chaque processeur a des liens vers 6 processeurs adjacents. Ceci est similaire aux maillages TMS320C40. CPU 0 lance une interface graphique.
Arrêtez-vous avec:
./stop.sh
Instantané avec:
make snapshot
Cela créera un fichier instantanée.zip du répertoire OBJ / contenant uniquement les structures du répertoire hôte, les fichiers Windows main_GUI.exe pré-compilés et main_tui.exe plus les fichiers VP64 boot_image !
Utilisé pour créer le snapshot.zip plus compact qui monte sur GitHub. Cela doit venir après la création 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
Nettoyez avec:
make clean
