Inferno64 is a fork of Inferno whose Dis virtual machine, Limbo compiler, and hosted emulator build for a 64-bit pointer model in addition to the original 32-bit one. This means that Inferno itself, its emu and the Dis VM can run anywhere, Limbo and userspace should run the same, no matter where you run them (with the exception of userspace programs that need more addressing space than 32 bits can provide.)
Also in this release is some kick-ass userspace improvements.
Something to be noted, another project (also named Inferno64) is inferior as it uses an ILP64 ABI model instead of an LP64 one, which means the size of an int in Limbo (the supposedly super-portable language compiled into Dis bytecode and run in a VM) is dependent on your platform. This means not only that the Dis bytecode is incompatible (between 32 and 64 bit pointer archs we know this), the source Limbo itself is incompatible, and gives undefined behavior. That inferior project is: https://github.com/caerwynj/inferno64
Nothing against that project author by the way, I started work on Inferno64 and did not know that his project existed, and I tried to use ILP64 (we have a branch for ILP64 that builds a working emu with JIT and everything, but it is just inferior for the purposes of Limbo's portability, which was a major design point of even having the Dis VM in the first place.)
That being said, there are still bugs that exist in every piece of software, this hobby ABI port notwithstanding. The bugs that remain are either normal logic bugs, a few use-after-frees, or heap corruption from the 32/64-bit pointer work — a known, bounded class, that depends on good C pointer handling discipline. If you run into and want to help catch one (your entire EMU crashes, for example), the heap-debugging guide explains why it happens and how to get a clean core + log on the first fault, so we can fix it.
Clone it and run one command in the project root (assuming you have build-essential):
make runThis will build Inferno64 from source, and should be all you need to poke around. To do different builds and hack on it such as running emu directly, the JIT, debugging — see the documentation below.
Most documentation lives under docs/, organised as an intent based index — start there:
docs/README.md.
| if you want to: | see |
|---|---|
| prerequisites, build, pick a profile, run emu directly, debug | docs/ON_BUILDING.md |
| Learn about the Limbo language | docs/ON_LIMBO.md |
| Write Limbo userspace applications | docs/ref/limbobyexample/ (worked examples) + concurrency |
| Write C in Inferno in general (Plan 9 dialect, types, and error model) | docs/ON_C_IN_INFERNO.md |
| Write C that will interact with the Dis VM (interfaces and wrappers and such, LP64 related considerations) | docs/ON_C_IN_DIS.md |
And there are many other autonomously documented Inferno subsystems there —
9P/Styx, the kernel,
the emulator, graphics (Draw/Tk/Prefab),
Charon (the web browser), networking & TLS,
namespaces, and the JIT — again, check
out docs/README.md
Note — the native (
os/) kernel is uniprocessor. On every board, however many cores the hardware has, it boots and runs on one; the others are left parked. You get real concurrency (many procs, channels, the scheduler) but no parallelism, and the locking is uniprocessor-grade — do not assume two things run at once. See the kernel doc. (This is a native-kernel property only; hostedemuuses the host OS's threads and does run across cores.)
One of the goals of this fork is a proper test suite (see Goals below), and it
has grown into one. Everything lives under tests/, one suite per layer —
C unit tests with 32-bit and big-endian canaries run under qemu-user, a
TAP-emitting Dis VM + Limbo regression suite, a JIT bit-equivalence gate, a
Charon rendering bench, a native-kernel end-to-end suite that boots qemu and
drives the serial console, and a 64→32-bit narrowing lint. The whole thing is
fronted by one pre-push gate:
make checkwhich runs the per-platform capability matrix and prints a PASS/FAIL table.
The map of which suite covers what, and the conventions they share, is
docs/ON_TESTING.md.
Yes, YOUR Limbo source code will. Your .dis binaries will likely not.
This is the main reason I went with an LP64 model instead of ILP64. If you try to distribute a .dis bytecode binary, then no, it will likely not, because turns out pointer models actually matter a lot. ILP64 guarantees nothing between platforms.
I have a few ideas on how to nicely handle this for users,
(right now I wrote a hey this .dis file is wrong for this platform: recompile it
handler, but as for how to make this more portable (allow for distribution of
.dis files) - I might just bundle the source with the .dis files... idk.
It's an open design question for me.
Maybe a package manager that will recompile .dis on every target arch, you upload the source, the repo will basically do CI. TBD.
No, I am doing my own thing, but if they want to talk to me then that's fine.
- Make Inferno run nicely on a LP64 ABI
- Make JIT compilation worth it
- Make a proper test suite and harnesses to find memory bugs fast and make debugging easier
- Modernize some of the userspace applications to where 'i like them' and they are nice to use
- Make some backward compatible improvements to Limbo (flesh out the undocumented Generics feature, improve compiler hints, etc)
- Improve Inferno documentation
- Whatever else I want (might port the kernel too, may be able to take from the 9front doofuses)
I'll stick some screenshots or a video here once I get userspace to where I like it.
I found it fitting to use the demon machine (claude mostly) to actually do the implementation for most of the mechanical work, building out tests, and the like. Considering this OS is hell themed, I figure it is fitting that an evil machine spirit would be forced to work on its own prison, unlike TempleOS, which only should be touched by the hands of those with Divine Intellect.
I have been programming for about 12 years, and only 2 of those have been with a demon machine, and I have found great utility in this tool's workflow. So, another part of this is the 'how to work on very complex software with this tool, effectively.'
I use a few workflows, depending on the work :^)
However, the main ones all center around an effective debugging harness that allows a vision model to actually drive the graphical desktop, attach a debugger to processes, and not get caught up by inferno's kind of crappy mk build tool.
For the graphical desktop work, I do the inferno development on a DGX Spark on the network, and set up emu under a x virtual framebuffer and display, which is hosted by a vnc server. The demon machine can use xdotool and interact with the display while I can simultaneously view and interact with the desktop over VNC. It makes "hey charon's navigation buttons aren't working, look" super simple, and makes it easier to catch when the demon machine is getting something wrong.
For the debugging and actually catching and dumping cores, we have to run emu with some build options and just make sure the demon machine knows about them, and it can use a gdb-mcp server (written by this dude: https://github.com/Ipiano/gdb-mcp) to work with gdb efficiently. This has been the main workflow for dealing with LP64 related bugs when using the desktop normally. It's very hard to track down some of these, as there's a few interface layers between Limbo's Dis VM, the C space, and just finding where the actual root cause of a problem is. I am sure this is standard method for finding these issues in a port, I'm just writing about it since that's what I did.
This fork includes some others' work:
- Limbo by Example (
docs/ref/limbobyexample/) is by Sean "henesy" Hinchee — https://github.com/henesy/limbobyexample - The Dis VM regression suite under
tests/dis/draws on the test programs in caerwynj's inferno-lab — https://github.com/caerwynj/inferno-lab
Mostly these are included here for convenience
Inferno® is a distributed operating system, originally developed at Bell Labs, but now developed and maintained by Vita Nuova® as Free Software. Applications written in Inferno's concurrent programming language, Limbo, are compiled to its portable virtual machine code (Dis), to run anywhere on a network in the portable environment that Inferno provides. Unusually, that environment looks and acts like a complete operating system.
Inferno represents services and resources in a file-like name hierarchy. Programs access them using only the file operations open, read/write, and close. `Files' are not just stored data, but represent devices, network and protocol interfaces, dynamic data sources, and services. The approach unifies and provides basic naming, structuring, and access control mechanisms for all system resources. A single file-service protocol (the same as Plan 9's 9P) makes all those resources available for import or export throughout the network in a uniform way, independent of location. An application simply attaches the resources it needs to its own per-process name hierarchy ('name space').
Inferno can run 'native' on various ARM, PowerPC, SPARC and x86 platforms but also 'hosted', under an existing operating system (including AIX, FreeBSD, IRIX, Linux, MacOS X, Plan 9, and Solaris), again on various processor types.
This repository includes source code for the basic applications, Inferno itself (hosted and native), all supporting software, including the native compiler suite, essential executables and supporting files.