LPMuds.net

Glad to see this forum is back!

Here's what's happening with FluffOS v2017 and v2019.

The driver main repository is at https://github.com/fluffos/fluffos/ , the best way to communicate is either on github issue, or on https://forum.fluffos.info , the offical website is at https://www.fluffos.info

v2019 contains everything since v2017, also comes with native UTF8 support, built-in weboscket support with xtermjs , you could get your mud web terminal enabled in minutes!

Let me know if you meet any issue trying it out.

In August 2019, I finally finalised the JIT compiler for DGD. It is implemented as an extension module, so that it will work with both DGD and Hydra, and indeed makes use of LLVM. It does not yet work on Windows, but should work on any other platform with LLVM support; it was tested on i386, x86_64 and ppc.

The extension starts and then communicates with an external program, which decompiles LPC bytecode to LLVM IR, and then uses clang to create a native shared object which the extension can load into DGD's memory. LPC bytecode files, LLVM IR files and shared object files are all cached, so that this translation needs to happen only once.

Keeping the LPC=>LLVM decompiler separate from DGD avoids issues with possible memory leaks and crashes, though of course an error in the bytecode translation could still be fatal. While translating a LPC bytecode image to a shared object takes much longer than an inline JIT compiler would, it runs completely independently from DGD, which is never delayed. Even loading the shared object into DGD's runtime memory is handled by a separate thread.

DGD: https://github.com/dworkin/dgd
LPC extension modules: https://github.com/dworkin/lpc-ext

As some folks noticed, there was another pretty prolonged outage of the LPmuds.net forum. This was due to a very heavy travel schedule, and not having had time to fix a hosting problem.

Please let me know if I've goofed in restoring things. As always, please remember to be courteous and helpful. Please note that Adam is your day to day overlord...I just keep the lights on.

Another direction you could take with FluffOS is improve the bytecode VM.

I did this for DGD as a prerequisite for JIT compilation.  Getting rid of lvalues as an explicit type gave me a speedup of 10-30%.

STM has the problem that it appears to scale worse than a well-designed implementation using locking, and you still have most of the same design headaches as you have with locking for multi-threaded code. Hydra doesn't require or implement STM, though it uses some of the same underlying ideas.

In any case, FluffOS & DGD are already overpowered for MUDs on present-day hardware, and DGD with JIT compilation is ridiculously overpowered. The speedup offered by JIT compilation will probably not play out in the realm of MUDs.