Chrysalisp es un sistema operativo paralelo de 64 bits, MIMD, multi-CPU, múltiples de múltiples núcleos, múltiples usuarios de usuarios con características como una GUI, terminal, ensamblador OO, bibliotecas de clases, compilador C-Script, Interpreter Lisp, depugger, perfilador, motor de vectores y más. Admite macOS, Windows y Linux para X64, Riscv64 y ARM64 y eventualmente se moverá hacia el metal desnudo. También permite el modelado de varias topologías de red y el uso de Chrysalib Hub_Nodes para unir redes heterogéneas host. Tiene un conjunto de instrucciones de CPU virtuales y un poderoso sistema de objeto y clase para el ensamblador y los idiomas de alto nivel. Tiene unión y carga dinámica a nivel de función, y un terminal de comando con una interfaz familiar para aplicaciones de línea de comandos de estilo PUBE. También se proporciona un intérprete común similar a Lisp.









Únase a nosotros en #Chrysalisp-Os: Matrix.org para bromas. Element.io Room recomendada.
Chrysalisp se puede usar en macOS, Windows y Linux. Admite CPU X64, ARM64 y RISCV64. También es compatible con un emulador de CPU de software VP64 utilizado para el proceso de instalación, pero esto se puede usar, con la opción -e , en plataformas donde no hay compatibilidad con CPU nativo actualmente, como el sistema de tiempo de ejecución. Se ejecuta en un entorno alojado mientras se realiza la experimentación, pero eventualmente se hará pasar por metal desnudo. En el futuro, planeo crear una imagen de arranque de VM para electrodomésticos unikernel y un objetivo websembly para usar dentro de los navegadores web.
Chrysalisp permite la simulación de varias topologías de red utilizando enlaces punto a punto. Cada CPU en la red se representa como un proceso de host separado, y los enlaces punto a punto utilizan la memoria compartida para simular conexiones bidireccionales de CPU a CPU. El diseño intencionalmente no incluye redes globales basadas en bus.
El proyecto Chrysalib, https://github.com/vygr/chrysalib, habilita el uso de cables IP y USB3/USB2 prolífico "copia" de chip para crear redes host de host heterogéneas. Esto permite a los usuarios conectar sus MacBooks, Linux, Windows Machines y PI4 para crear sus propias redes LAN o WAN, lo cual es bastante bueno.
Chrysalisp utiliza un conjunto de instrucciones de CPU virtuales para eliminar el uso de instrucciones nativas X64, ARM64, RISCV64 o VP64. Actualmente, se compila directamente con el código nativo, pero tiene la capacidad de traducirse también al formulario de código de byte y usar la traducción de tiempo de ejecución.
Para evitar la necesidad de hacer malabarismo para el paso de los parámetros, todas las funciones definen su interfaz de registro, y las fuentes y destinos de parámetros se asignan automáticamente utilizando un tipo topológico. Si se detectan asignaciones que no son DAG, el usuario puede dirigirse a ellos con un temporal. El software también incluye operadores para facilitar la unión de parámetros a funciones dinámicas unidas, direcciones relativas, grupos de cadenas automáticamente definidas, referencias y valores de marco de pila local. Los parámetros de salida que no se usan pueden ignorarse con un bajo.
Chrysalisp tiene un poderoso objeto y un sistema de clase que no se limita solo al ensamblador, pero es tan capaz como un lenguaje de alto nivel. Permite la definición de clases estáticas o clases virtuales con métodos en línea, virtual, final, estático y de anulación. La GUI y el LISP se construyen utilizando este sistema de clase.
Tiene unión y carga dinámica a nivel de función. Las funciones están cargadas y ligadas a pedido a medida que se crean y distribuyen tareas. Actualmente, las funciones se cargan desde el sistema de archivos CPU donde se encuentra la tarea, pero en el futuro, vendrán del objeto del servidor con el que se creó la tarea y se transportará a través de la red según sea necesario. Las funciones se comparten entre todas las tareas que usan el mismo objeto del servidor, por lo que solo se carga una copia de una función, independientemente de cuántas tareas lo usen.
Se accede a las funciones del sistema a través de un conjunto de clases estáticas, lo que facilita el uso y elimina la necesidad de recordar ubicaciones de funciones estáticas, y también desacopla la fuente de los cambios a nivel del sistema. Las definiciones de interfaz para estas funciones se pueden encontrar en los archivos sys/xxx.inc .
Un terminal de comando con una interfaz familiar para aplicaciones de línea de comandos de estilo Pipe se proporciona con Args Vector, Stdin, Stdout, Stderr, etc. Clases para una fácil construcción de maestros y esclavos de tuberías, con anidación arbitraria de tuberías de línea de comandos. Si bien esta no es la mejor manera de crear aplicaciones paralelas, es muy útil para la composición de las herramientas y oculta todo el mensaje que pasa detrás de una API basada en transmisiones familiares.
Se proporciona un intérprete LISP común. Esto está disponible desde la línea de comandos, a través del comando lisp . Para construir todo el tipo de sistema (make) , calcula la carga de trabajo de compilación mínima, o (make-all) para hacer todo independientemente, en el símbolo del sistema LISP. Este LISP tiene una capacidad de 'fragmentos' C-script para permitir la mezcla de expresiones compiladas C-script dentro de la asignación y el código de llamadas de funciones. Existe un pase de optimización elemental para estas expresiones. Tanto el ensamblador virtual como el compilador C-script están escritos en LISP, miren en el Lib/ASM/Code.InC , Lib/ASM/XXX.InC , Lib/ASM/FUNC.Inc , Lib/Trans/X86_64.InC , Lib/Trans/Arm64.InC y Lib/ASM/VP.InC sobre cómo se hace esto. Algunas de las primitivas LISP se construyen a través de un script de arranque que cada instancia de una clase LISP se ejecuta en la construcción, vea class/lisp/root.Inc para más detalles. El entorno de compilación y fabricación, junto con todos los comandos de compilación y fabricante, se crean a través de la herramienta de línea de comandos LISP en lib/asm/asm.Inc , nuevamente esta auto se ejecuta para cada instancia del comando lisp que se ejecuta desde el terminal. Puede extender esto con cualquier cantidad de archivos adicionales, simplemente colóquelos después del comando LISP y se ejecutarán después del archivo lib/asm/asm.Inc y antes del procesamiento de stdin.
No tenga la idea de que debido a que se codifica en el LISP interpretado, el ensamblador y el compilador serán lentos. ¡Una compilación de un sistema totalmente limpio desde la fuente, incluida la creación de un archivo de imagen de arranque previo recursivo recursivo, adquiere el orden de 2 segundos en un MacBook Pro 2014! Ciclo de desarrollo (make) y (remake) por debajo de 0.5 segundos. ¡No es lento!
Las tablas de enrutamiento de enlaces de red se crean al iniciar un enlace, y el proceso se distribuye en la naturaleza, cada enlace comienza un relleno de inundación que finalmente alcanza todas las CPU y en el camino ha marcado todas las rutas de una CPU a otra. Se encuentran todas las rutas más cortas, los mensajes que salen de la CPU se asignan a un enlace a medida que el enlace se vuelve gratuito y múltiples enlaces pueden y hacer mensajes de enrutamiento a través de rutas paralelas simultáneamente. Los mensajes grandes se dividen en fragmentos más pequeños en el envío y reconstruido en el destino para maximizar el uso de las rutas disponibles.
La opción de línea de comandos -run inicia tareas en el arranque de esa CPU, como la GUI experimental (un trabajo en progreso, -run gui/gui/gui.lisp ). Puede cambiar el script de lanzamiento de la red para ejecutar más de una sesión de GUI si lo desea, intente iniciar la GUI en más de CPU 0, ¡busque funcs.sh en la función boot_cpu_gui ! :)
La opción de línea de comandos -l crea un enlace, actualmente hasta 1000 CPU están permitidas, pero eso es fácil de ajustar. Los archivos de enlace de memoria compartida se crean en la carpeta TMP /TMP , por lo que, por ejemplo , TMP /000-001 sería el archivo de enlace para el enlace entre CPU 000 y 001.
Una red de ejemplo vista con PS se ve así para una red de malla 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
Eche un vistazo a docs/intro.md para obtener instrucciones para comenzar con todas las plataformas compatibles.
La GUI experimental requiere que se instale la biblioteca SDL2 .
Consíguelos a través de su administrador de paquetes, en Linux con:
sudo apt-get install libsdl2-dev
O en Mac a través de Homebrew.
brew install sdl2
Eche un vistazo a docs/intro/intro.md para las instrucciones específicas de la plataforma. Lo siguiente es para sistemas OSX y Linux. Windows tiene un main.exe prebuilado proporcionado, o puede configurar Visual Studio para compilar las cosas usted mismo si lo desea.
La primera vez que descargue Chrysalisp, solo tendrá la imagen de arranque del emulador VP64. Debe crear las imágenes de arranque nativas por primera vez. Esto es un poco más lento que las botas y compilaciones del sistema posteriores, pero nos permite mantener el archivo Snapshot.zip lo más pequeño posible.
Si está en Linux o Mac a través de Homebrew:
make install
O en Windows
install.bat
make
./run_tui.sh [-n num_cpus] [-e] [-b base_cpu]
TEXTO Interfaz de usuario basada en red totalmente conectada. Cada CPU tiene enlaces a cualquier otra CPU. Cuidado con esto, ya que puede terminar con una gran cantidad de archivos de enlaces y regiones de memoria compartidas. CPU 0 lanza un terminal al sistema host.
./run.sh [-n num_cpus] [-e] [-b base_cpu]
Red totalmente conectada. Cada CPU tiene enlaces a cualquier otra CPU. Cuidado con esto, ya que puede terminar con una gran cantidad de archivos de enlaces y regiones de memoria compartidas. CPU 0 lanza una GUI.
./run_star.sh [-n num_cpus] [-e] [-b base_cpu]
Red de estrella conectada. Cada CPU tiene un enlace a la primera CPU. CPU 0 lanza una GUI.
./run_ring.sh [-n num_cpus] [-e] [-b base_cpu]
Red de anillo conectada. Cada CPU tiene enlaces a la siguiente y anterior CPU. CPU 0 lanza una GUI.
./run_tree.sh [-n num_cpus] [-e] [-b base_cpu]
Red conectada a los árboles. Cada CPU tiene enlaces a su CPU principal y hasta dos CPU infantiles. CPU 0 lanza una GUI.
./run_mesh.sh [-n num_cpus on a side] [-e] [-b base_cpu]
Red conectada de malla. Cada CPU tiene enlaces a 4 CPU adyacentes. Esto es similar a las mallas transputadoras. CPU 0 lanza una GUI.
./run_cube.sh [-n num_cpus on a side] [-e] [-b base_cpu]
Network Connected Cube. Cada CPU tiene enlaces a 6 CPU adyacentes. Esto es similar a las mallas TMS320C40. CPU 0 lanza una GUI.
Detente con:
./stop.sh
Instantánea con:
make snapshot
Esto creará un archivo snapshot.zip del directorio OBJ/ que contiene solo las estructuras del directorio de host, los Windows pre-compilados Main_Gui.exe y Main_tui.exe más los archivos VP64 Boot_image .
Se usa para crear la snapshot.zip más compacta que sube en GitHub. ¡Esto debe venir después de la creación del conjunto de boot_image (make-all-platforms) !
obj/vp64/VP64/sys/boot_image
obj/x86_64/WIN64/Windows/main_gui.exe
obj/x86_64/WIN64/Windows/main_tui.exe
Limpiar con:
make clean