Node9: Inferno kernel with LuaJIT instead of the Dis virtual machine | Hacker News Reader

Node9: Inferno kernel with LuaJIT instead of the Dis virtual machine

github.com

116 pointsf2f21 comments

Hi...

I'm the author of Node9, so it's pretty cool that this has gone semi-viral. It's taken quite a bit of heavy lifting to blend Inferno and LuaJIT together. There's still a lot of work to be done, but it compiles on OSX and works. Please be patient as I hack the premake files to build properly on Linux/BSDs. Eventually porting will just work using libuv, but until then I'm hacking away.

For those wondering about Dis vs LuaJIT, Dis ultimately presented some issues when it came to multithreading and I wasn't about to JIT compile Lua to Dis when I had LuaJIT. :) Jim Burnes

Awesome job! While you have been focused on having this be a hosted OS, is there anything preventing (or at least making it difficult) to run on bare metal? If it is possible to do it on x86, what difficulties are there in porting it to other architectures?

Thanks, trsohmers. In theory, no major issues. Inferno comes with both a hosting mode (called 'emu') and bare metal implementations for numerous architectures. I've spent a good deal of my time porting the cross-platform hosted version to libuv. With a little careful hacking of the premake files to create a bare metal cross compile environment it would work. It's a decent amount of work. If you're really interested in that wait until the libuv premake version stabilizes for x86 and BSD/Linux and give it a shot.

This is seriously cool !

9P servers can be mounted (thanks to plan9port) as a (virtual) filesystem. Therefore, any utility, in any language, can interact with the cloud simply by writing and reading files, without even knowing is the system it interacts with is the actual hard drive, a computer on the other side of the planet, or a composite cloud system.

Seeing the power of Plan9/Inferno ported to Lua opens up some interesting perspectives.

I'm eager to play with this, congrats !

Ok yes, but ipv4 and NAT :( and firewalls.

drawterm for example requires three ports.

Still it would be nice to tear down the wall between local machines, and make a multi machine computer. There is a fancy name for this that I have forgotten.

Is there a place where 9p namespace enthusiasts can unite and change the world? It is silly that modern computers (using the term loosely) are so isolated from each other even though they are networked.

There is a fancy name for this that I have forgotten.

Multi-tenant?

Is there a place where 9p namespace enthusiasts can unite and change the world?

There's #cat-v, the 9fans mailing list and so on, but I don't think any of today's Plan 9 enthusiasts are really intent on "changing the world". They just work for themselves.

hi deadbeef

1. ipv4 isn't so much a problem. there's a driver for v6 I just haven't used it yet.

2. NAT and firewalls. I'm a software engineer that specializes in security so I'm well aware of these issues. I'm not implementing the windowing system of Inferno/Plan9 so drawterm's not so much an issue. Node9 is more about distributed computing than distributed windowing systems. You want access to 9p services, just connect via the standard 9p port (or whatever port you want to export on).

As soon as /prog driver is finished I'm going to interface the debug system in ZeroBraneStudio to it so you can do distributed debugging.

Single System Image.

I don't know much about lua or LuaJit, but I know a lot about Inferno and the Dis VM. Dis is a really, really nice VM design (and pretty fast too!). It's a pleasure to generate dis code (say, from a compiler). I'd like to see more languages ported to dis.

I don't know much about Infero, but this VM alsways seemed odd to me.

On the one hand inferno clearly has a plan9 background. In Plan9 IPC is done via files.

But in Inferno IPC is sometimes done with files (there is /dev/screen I guess), and sometimes with the DIS VM (like interacting with the Window Manager).

I know a lot about Lua and LuaJIT, but never heard of Dis until today. After reading a bit about Dis, it sounds like the two have very different designs.

Dis is defined by its instruction set. The instruction set is typed, so the programming language pretty much needs to by statically typed (Lua is dynamically typed). It appears to only support interpreted or fully-compiled modes; ie. it doesn't appear to support a hybrid interpreted/compiled mode where hotspots get compiled (I can't be 100% sure about this from what I read though).

LuaJIT is defined by the Lua programming language -- it has bytecode internally, but this is not really designed to be targeted by other code generators, and the bytecode is heavily biased towards Lua language semantics (some smart people tried compiling JavaScript to LuaJIT and made a lot of progress, but ultimately found that even the slight incompatibilities between JavaScript and Lua made life very difficult: https://tessel.io/blog/112888410737/moving-faster-with-io-js).

LuaJIT is built on a fast interpreter written in assembly language, and uses trace compiling to identify hot traces and JIT-compiles only those. Its compiler is pretty sophisticated, using a SSA internal representation and many optimizations (http://wiki.luajit.org/Optimizations). I suspect this is far beyond what the Dis VM does in its JIT compiler -- the Dis VM emphasizes how many Dis VM instructions can be translated directly into CPU instructions. It seems to expect that most optimization will happen at byte-code generation time, which is a more practical assumption with statically-typed languages.

Overall I expect that LuaJIT is as fast or faster than Dis, despite Lua being a dynamically-typed language. LuaJIT is one of the fastest VMs out there. But it's not a multi-language VM like Dis could potentially be.

> But it's not a multi-language VM like Dis could potentially be.

Dis also supports Java.

http://doc.cat-v.org/inferno/java_on_dis/

Just a side note, because it's not directly relevant to this conversation, but I love how useful and powerful libuv has become. I'm not a huge fan of JavaScript or Node, but the Node project's work on libuv is a great boon to a large number of projects, for which it is the perfect level of abstraction between raw non-portable OS interfaces and opinionated, performance-sacrificing language APIs.

true

"It make take a few iterations of the source code with the help of other users to make it fully portable "out of the box.""

Need any help with porting to Net/Free/OpenBSD?

gwu73: sure. Right now I need to stabilize the premake multi-platform configuration settings. Didn't expect this level of interest so soon :)

Great work! I created a build script for Node9: https://gist.github.com/hnakamur/13808187bf59e47456c3

awesome. thanks man. i forgot that i was using penlight. :)

Is there an image file I can grab and run with qemu?

Great Hack !

thanks

Reply on news.ycombinator.com