Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dworkin

Pages: [1] 2 3
Phantasmal Phorum / Re: Looking For 64bit Bundle
« on: February 04, 2021, 01:01:36 pm »
The bundled version of DGD works fine on 64 bit operating systems (though it compiles with a few warnings), but it's almost 16 years old. You can find more up-to-date versions of DGD and Phantasmal here: and

Drivers / Re: JIT compiler revisited for Fluffos/dgd
« on: March 26, 2020, 09:54:09 am »
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.

LPC extension modules:

Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 07:29:12 am »
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%.

Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 05:23:33 am »
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.

Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 10, 2019, 10:41:15 am »
Silenus, I started working on the JIT compiler a long time ago, but didn't have time to complete it until recently.  I only decided to make use of LLVM a few months ago, before that I was still considering decompiling to C, instead.  I made the first point release of the JIT compiler just now.

The situation for DGD is similar to FluffOS, the community has shrunk and those who still use it are doing their own thing.  As a MUD server engine, DGD was probably feature-complete around 2002, and there is not a lot of interest in new releases.  And to top it off, I spend most of my free time on Hydra now, which is not yet used by anyone at all.  ;D

Drivers / Re: New fluffos repo containing the 2.28 version.
« on: August 17, 2019, 08:33:08 am »
I noticed that you started an issue for JIT compilation, where you consider the option to compile to LLVM IR directly.

Another option would be to do both, preserving lightning-fast LPC compilation. For JIT compilation for DGD, I chose to compile from VM bytecode to LLVM IR in multiple passes; detecting basic blocks, determining the types of expressions, doing dataflow analysis, and finally generating LLVM IR which can be compiled with clang. I have this mostly working (mud boots and I can walk around), but there are a few bugs to iron out.

You can find the code at  It could probably be adopted for FluffOS without too much difficulty.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 03:09:36 pm »
Does it make sense for function pointers to persist when object references don't?

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 08:45:51 am »
I might be wrong about this but I suspect that function pointers in dgd work be okay if you assume a sort of late binding i.e. make the function point just hold the object or program on which the pointer is called plus a string and arguments. I.e. a sort of on demand delayed call_other with no guarantees that it points to anything of if it ever did. I am not sure however with object upgrades how lambda closures (anon-funcs) could be made to work since in principle you either carry the code with the variable or compile the code into an object which is nameless and point to it. Could you not have an nameless object hold the code and have the function pointer point to the code in a nameless object that gets compiled on the fly? Depending on the copy semantics one could perhaps even use an lwo.

This discussion is wandering far afield, but the difficulty in combining object upgrading with anonymous functions is that you cannot unambiguously match an anonymous function reference to code in a newly upgraded object. Thus anonymous functions cannot be automatically upgraded.

None of this pertains to Fluffos, which doesn't have object upgrading.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 03:12:56 am »
I think you are misremembering, Quixadhal. Fluffos doesn't allow recompilation of an object while retaining its data. DGD does, and that's one of the reasons why DGD has no function pointers.

Drivers / Re: Thoughts on licensing issue
« on: April 03, 2013, 10:12:34 am »
Actually, you don't need multithreading.  You need to not abort LPC thread execution when the time's up, but save the stack machine's state for that object and context switch to the next one.

Right now, if a thread exceeds their eval ticks, it just gets killed.  How hard would it be to save state and restore it next time around the loop?

That is so 20th century.  Event-driven, non-blocking, asynchronous I/O models are the height of fashion now: Node.js, Akka, Vert.x.

Drivers / Re: proposal for multi-threaded comm changes.
« on: March 07, 2013, 06:37:05 pm »
I don't know the internals of FluffOS, so I don't know what can of worms you're opening by introducing multi-threading at that level.  Since FluffOS's LPC isn't itself multi-threaded (unlike DGD's Hydra), I suppose it wouldn't be too ugly as long as you were careful about mutex-locking the code that's fetching socket input and dumping it into the processing buffers (and likewise for output).

Hydra on Linux uses epoll_wait(), but for a single-threaded server select() can be more efficient because it can collect multiple events per call. The higher the activity/connections ratio, and the longer LPC execution takes (making it more likely that input events will be grouped together), the more efficient select() becomes.

Because one of my high level goals is to reach both 1st & 3rd world infrastructures, I'm trying to figure out an infrastructure model that would be essentially UI agnostic.  Maybe something Client/Server Obj/Event ...

People in third-world countries don't have computers, but they do have phones; in a few years they'll have Android smartphones. Given that you want to reach this enormous population, perhaps you should drop support for the tiny and shrinking group of people who will connect with telnet-like clients from first-world computers.  ;)

Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 09:59:43 am »
To return to the subject of modern mud drivers, if DGD were not available today, I would take a look at Node. Javascript, event-driven like LPC, and it's a server not a script.

Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 09:31:30 am »
I'm entirely certain you were successful in pulling all the game-mechanical cruft out of DGD, and hopefully all of the freakishly broken "performance optimizations" too.  (My favorite is the behavior I discovered under LDMud after various of my daemon objects stopped working: if nothing attempts to call a function on an object via call_other() for some period of time, reset() stops getting called!  And there is no driver config switch for this behavior!  So awesome.  You can imagine how much of my hair I pulled out trying to debug that idiocy.)  The only assumption I had in mind for DGD was that of being a telnet server.

The telnet part is optional; some DGD mudlibs use HTTP.

Design Lab / Re: High Level Design Series: Blue Sky WISH List(s)
« on: July 16, 2012, 09:14:20 am »
I thought that some assumptions were in there that the system is going to be a Telnet server hooking up connections to objects.  Meaning, I didn't think DGD made you write your own socket handling model like Pike would.  If I'm wrong, I humbly apologize.

DGD is a server, yes; it doesn't make LPC into a scripting language, as Pike does.  But what about the game server assumptions?

Pages: [1] 2 3