{"id":15020617,"url":"https://github.com/vygr/chrysalisp","last_synced_at":"2026-03-09T13:07:37.037Z","repository":{"id":27084364,"uuid":"30551167","full_name":"vygr/ChrysaLisp","owner":"vygr","description":"Parallel OS, with GUI, Terminal, OO Assembler, Class libraries, C-Script compiler, Lisp interpreter and more...","archived":false,"fork":false,"pushed_at":"2025-04-08T10:54:39.000Z","size":181411,"stargazers_count":1626,"open_issues_count":4,"forks_count":100,"subscribers_count":70,"default_branch":"master","last_synced_at":"2025-04-11T04:59:42.076Z","etag":null,"topics":["aarch64","assembly","gui","linux","lisp","os","osx","raspberry-pi-3","vm","x86-64"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/vygr.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-02-09T18:29:50.000Z","updated_at":"2025-04-11T02:37:20.000Z","dependencies_parsed_at":"2023-09-25T19:21:10.628Z","dependency_job_id":"5cfc3171-a556-4026-ad4e-19e0cc772104","html_url":"https://github.com/vygr/ChrysaLisp","commit_stats":{"total_commits":8802,"total_committers":16,"mean_commits":550.125,"dds":0.06384912519881847,"last_synced_commit":"41c3254eb0ee6346bd8de84123cb48ed09136a4f"},"previous_names":[],"tags_count":59,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vygr%2FChrysaLisp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vygr%2FChrysaLisp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vygr%2FChrysaLisp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vygr%2FChrysaLisp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/vygr","download_url":"https://codeload.github.com/vygr/ChrysaLisp/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248345273,"owners_count":21088244,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aarch64","assembly","gui","linux","lisp","os","osx","raspberry-pi-3","vm","x86-64"],"created_at":"2024-09-24T19:55:20.545Z","updated_at":"2026-03-09T13:07:36.961Z","avatar_url":"https://github.com/vygr.png","language":"C++","readme":"# ChrysaLisp\n\nChrysaLisp is a 64-bit, MIMD, multi-CPU, multi-threaded, multi-core, multi-user\nparallel operating system with features such as a GUI, terminal, OO Assembler,\nclass libraries, C-Script compiler, Lisp interpreter, debugger, profiler,\nvector font engine, and more. It supports MacOS, Windows, and Linux for x64,\nRiscv64 and Arm64 and eventually will move to bare metal. It also allows the\nmodeling of various network topologies and the use of ChrysaLib hub_nodes to\njoin heterogeneous host networks. It has a virtual CPU instruction set and a\npowerful object and class system for the assembler and high-level languages. It\nhas function-level dynamic binding and loading and a command terminal with a\nfamiliar interface for pipe-style command line applications. A Common Lisp-like\ninterpreter is also provided.\n\n![](./screen_shot_1.png)\n![](./screen_shot_2.png)\n![](./screen_shot_3.png)\n![](./screen_shot_4.png)\n![](./screen_shot_5.png)\n![](./screen_shot_6.png)\n![](./screen_shot_7.png)\n![](./screen_shot_8.png)\n![](./screen_shot_9.png)\n\nJoin us at #ChrysaLisp-OS:matrix.org for banter.\n[element.io room](https://app.element.io/#/room/#ChrysaLisp-OS:matrix.org)\nrecommended.\n\nChrysaLisp can be used on MacOS, Windows and Linux. Supports x64, arm64 and\nriscv64 CPUs. It also supports a VP64 software CPU emulator used for the\ninstall process, but this can be used, with the `-e` option, on platforms where\nno native CPU support currently exits, as the runtime system. It runs on a\nhosted environment while experimentation is being done, but eventually it will\nbe transitioned to run on bare metal. In the future, I plan to create a VM boot\nimage for UniKernel appliances and a WebAssembly target for use within web\nbrowsers.\n\nChrysaLisp allows for the simulation of various network topologies utilizing\npoint-to-point links. Each CPU in the network is represented as a separate host\nprocess, and point-to-point links utilize shared memory to simulate CPU-to-CPU,\nbidirectional connections. The design intentionally does not include global\nbus-based networking.\n\nThe ChrysaLib project, https://github.com/vygr/ChrysaLib, enables the use of IP\nand USB3/USB2 Prolific chip \"copy\" cables to create heterogeneous host\nnetworks. This allows users to connect their MacBooks, Linux, Windows machines\nand PI4's to create their own development LAN or WAN networks, which is pretty\ncool.\n\nChrysaLisp uses a virtual CPU instruction set to eliminate the use of x64,\nARM64, RISCV64, or VP64 native instructions. Currently, it compiles directly to\nnative code, but it has the capability to also be translated to byte code form\nand use runtime translation.\n\nTo avoid the need for register juggling for parameter passing, all functions\ndefine their register interface, and parameter sources and destinations are\nautomatically mapped using a topological sort. If non-DAG mappings are\ndetected, the user can address them with a temporary. The software also\nincludes operators to make it easy to bind parameters to dynamic bound\nfunctions, relative addresses, auto-defined string pools, references, and local\nstack frame values. Output parameters that are not used can be ignored with an\nunderscore.\n\nChrysaLisp has a powerful object and class system that is not limited to just\nthe assembler but is quite as capable as a high level language. It allows for\nthe definition of static classes or virtual classes with inline, virtual,\nfinal, static, and override methods. The GUI and Lisp are built using this\nclass system.\n\nIt has function-level dynamic binding and loading. Functions are loaded and\nbound on demand as tasks are created and distributed. Currently, functions are\nloaded from the CPU file system where the task is located, but in the future,\nthey will come from the server object that the task was created with and will\nbe transported across the network as needed. Functions are shared among all\ntasks that use the same server object, so only one copy of a function is\nloaded, regardless of how many tasks use it.\n\nThe system functions are accessed through a set of static classes, which makes\nit easy to use and eliminates the need to remember static function locations,\nand also decouples the source from changes at the system level. The interface\ndefinitions for these functions can be found in the *sys/xxx.inc* files.\n\nA command terminal with a familiar interface for pipe style command line\napplications is provided with args vector, stdin, stdout, stderr etc. Classes\nfor easy construction of pipe masters and slaves, with arbitrary nesting of\ncommand line pipes. While this isn't the best way to create parallel\napplications it is very useful for the composition of tools and hides all the\nmessage passing behind a familiar streams based API.\n\nA Common Lisp like interpreter is provided. This is available from the command\nline, via the command `lisp`. To build the entire system type `(make)`,\ncalculates minimum compile workload, or `(make-all)` to do everything\nregardless, at the Lisp command prompt. This Lisp has a C-Script 'snippets'\ncapability to allow mixing of C-Script compiled expressions within assignment\nand function calling code. An elementary optimize pass exists for these\nexpressions. Both the virtual assembler and C-Script compiler are written in\nLisp, look in the *lib/asm/code.inc*, *lib/asm/xxx.inc*, *lib/asm/func.inc*,\n*lib/trans/x86_64.inc*, *lib/trans/arm64.inc* and *lib/asm/vp.inc* for how this\nis done. Some of the Lisp primitives are constructed via a boot script that\neach instance of a Lisp class runs on construction, see *class/lisp/root.inc*\nfor details. The compilation and make environment, along with all the compile\nand make commands are created via the Lisp command line tool in\n*lib/asm/asm.inc*, again this auto runs for each instance of the `lisp` command\nrun from the terminal. You can extend this with any number of additional files,\njust place them after the lisp command and they will execute after the\n*lib/asm/asm.inc* file and before processing of stdin.\n\nDon't get the idea that due to being coded in interpreted Lisp the assembler\nand compiler will be slow. A fully cleaned system build from source, including\ncreation of a full recursive pre-bound boot image file, takes on the order of 2\nseconds on a 2014 MacBook Pro ! Dev cycle `(make)` and `(remake)` under 0.5\nseconds. It ain't slow !\n\nNetwork link routing tables are created on booting a link, and the process is\ndistributed in nature, each link starts a flood fill that eventually reaches\nall the CPU's and along the way has marked all the routes from one CPU to\nanother. All shortest routes are found, messages going off CPU are assigned to\na link as the link becomes free and multiple links can and do route messages\nover parallel routes simultaneously. Large messages are broken into smaller\nfragments on sending and reconstructed at the destination to maximize use of\navailable routes.\n\nThe `-run` command line option launches tasks on booting that CPU, such as the\nexperimental GUI (a work in progress, `-run service/gui/app.lisp`). You can change\nthe network launch script to run more than one GUI session if you want, try\nlaunching the GUI on more than CPU 0, look in *funcs.sh* at the `boot_cpu_gui`\nfunction ! :)\n\nThe `-l` command line option creates a link, currently up to 1000 CPU's are\nallowed but that's easy to adjust. The shared memory link files are created in\nthe tmp folder */tmp*, so for example */tmp/000-001* would be the link file for\nthe link between CPU 000 and 001.\n\nAn example network viewed with ps looks like this for a 4x4 mesh network:\n\n```code\n./main_gui -l 011-015 -l 003-015 -l 014-015 -l 012-015\n./main_gui -l 010-014 -l 002-014 -l 013-014 -l 014-015\n./main_gui -l 009-013 -l 001-013 -l 012-013 -l 013-014\n./main_gui -l 008-012 -l 000-012 -l 012-015 -l 012-013\n./main_gui -l 007-011 -l 011-015 -l 010-011 -l 008-011\n./main_gui -l 006-010 -l 010-014 -l 009-010 -l 010-011\n./main_gui -l 005-009 -l 009-013 -l 008-009 -l 009-010\n./main_gui -l 004-008 -l 008-012 -l 008-011 -l 008-009\n./main_gui -l 003-007 -l 007-011 -l 006-007 -l 004-007\n./main_gui -l 002-006 -l 006-010 -l 005-006 -l 006-007\n./main_gui -l 001-005 -l 005-009 -l 004-005 -l 005-006\n./main_gui -l 000-004 -l 004-008 -l 004-007 -l 004-005\n./main_gui -l 003-015 -l 003-007 -l 002-003 -l 000-003\n./main_gui -l 002-014 -l 002-006 -l 001-002 -l 002-003\n./main_gui -l 001-013 -l 001-005 -l 000-001 -l 001-002\n./main_gui -l 000-012 -l 000-004 -l 000-003 -l 000-001 -run gui/gui\n```\n\n## Getting Started\n\nTake a look at the `docs/intro.md` for instructions to get started on all the\nsupported platforms.\n\nThe experimental GUI requires the **SDL2** library to be installed.\n\nGet them via your package manager, on Linux with:\n\n```code\nsudo apt-get install libsdl2-dev\n```\n\nOr on Mac via Homebrew.\n\n```code\nbrew install sdl2 sdl2_mixer\n```\n\n## Make/Run/Stop\n\nTake a look at the `docs/intro/intro.md` for platform specific instructions. The\nfollowing is for OSX and Linux systems. Windows has a pre-built main.exe\nprovided, or you can configure Visual Studio to compile things yourself if you\nwish.\n\n### Installing\n\nThe first time you download ChrysaLisp you will only have the vp64 emulator\nboot image. You must create the native boot images the first time round. This\nis a little slower than subsequent boots and system compiles but allows us to\nkeep the snapshot.zip file as small as possible.\n\nIf on Linux or Mac via Homebrew:\n\n```code\nmake install\n```\n\nOr on Windows\n\n```code\ninstall.bat\n```\n\n### Make\n\n```code\nmake\n```\n\n### Run\n\n```code\n./run_tui.sh [-n num_cpus] [-e] [-b base_cpu]\n```\n\nText user interface based fully connected network. Each CPU has links to every\nother CPU. Careful with this as you can end up with a very large number of link\nfiles and shared memory regions. CPU 0 launches a terminal to the host system.\n\n```code\n./run.sh [-n num_cpus] [-e] [-b base_cpu]\n```\n\nFully connected network. Each CPU has links to every other CPU. Careful with\nthis as you can end up with a very large number of link files and shared memory\nregions. CPU 0 launches a GUI.\n\n```code\n./run_star.sh [-n num_cpus] [-e] [-b base_cpu]\n```\n\nStar connected network. Each CPU has a link to the first CPU. CPU 0 launches a\nGUI.\n\n```code\n./run_ring.sh [-n num_cpus] [-e] [-b base_cpu]\n```\n\nRing connected network. Each CPU has links to the next and previous CPU's. CPU\n0 launches a GUI.\n\n```code\n./run_tree.sh [-n num_cpus] [-e] [-b base_cpu]\n```\n\nTree connected network. Each CPU has links to its parent CPU and up to two\nchild CPU's. CPU 0 launches a GUI.\n\n```code\n./run_mesh.sh [-n num_cpus on a side] [-e] [-b base_cpu]\n```\n\nMesh connected network. Each CPU has links to 4 adjacent CPU's. This is similar\nto Transputer meshes. CPU 0 launches a GUI.\n\n```code\n./run_cube.sh [-n num_cpus on a side] [-e] [-b base_cpu]\n```\n\nCube connected network. Each CPU has links to 6 adjacent CPU's. This is similar\nto TMS320C40 meshes. CPU 0 launches a GUI.\n\n### Stop\n\nStop with:\n\n```code\n./stop.sh\n```\n\n### Snapshot\n\nSnapshot with:\n\n```code\nmake snapshot\n```\n\nThis will create a *snapshot.zip* file of the *obj/* directory containing only\nthe host directory structures, the pre-compiled Windows *main_gui.exe* and\n*main_tui.exe* plus the VP64 *boot_image* files !\n\nUsed to create the more compact *snapshot.zip* that goes up on Github. This\nmust come after creation of `(make-all-platforms)` *boot_image* set !\n\n```code\nobj/vp64/VP64/sys/boot_image\nobj/x86_64/WIN64/Windows/main_gui.exe\nobj/x86_64/WIN64/Windows/main_tui.exe\n```\n\n### Clean\n\nClean with:\n\n```code\nmake clean\n```\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvygr%2Fchrysalisp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvygr%2Fchrysalisp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvygr%2Fchrysalisp/lists"}