LPMuds.net

I am thinking of writing an i3 client as an exercise to teach myself a bit about networking and C++. I was looking over the documents on wotf is this a good place to start? I assume that basically on top of a client written in lpc like the ones in gurbalib or ds I would need a mudmode parser. Otherwise I am good to go?

I was initially thinking about writing a JIT for either fluffos or dgd but came across this problem as a potential issue. I think dworkin indicates he has already started laying the groundwork for a JIT for dgd so I am wondering if it would be good idea to have one for fluffos or just modify dgd so it can run the same code as fluffos does (or something that is semantically close enough that it is easy to convert). Currently that project has a less restrictive license.

I noticed some old posts mentioning the inclusion of a jit compiler for fluffos might be in the works. Is this now no longer the case? I think that the upcoming 3.8 release of llvm with patchpoint and stackmaps might be suitable for this sort of thing. The work involved however is quite significant since fluffos unlike dgd has a lot of efuns and packages that directly manipulate the stack which would all have to be reimplemented to work with the new virtual machine. I am also curious also about the old c code generation that mudos IIRC use to have... Is this code still available somewhere? I am sort of curious how this problem was addressed given the plethora of efuns.

I am actually tempted to take a few months to work on this and give it a go. Converting the icode.c to generate llvm code directly and rewriting some of the apply and call hooks to call llvm::Functions pointed to by new program tables would be the main challenge.

Thanks Dworkin. I was at one point interested in trying to implement some sort of anon funcs into dgd hence the question. The issues I suspect are somewhat similar- since to save an anon func means also that the save file has a lifespan perhaps exceeding that of the program from which it is generated. For function pointers the problem might be resolvable by down stepping the method index reference back into a function name as a string and re-resolving it when the pointer is loaded from storage. The more general solution would be to keep a string representation of the code handy and recompile it on load. That might be quite a lot of work since one would have to hack into the compiler as well. I havent explored yet as to how difficult it would be to get the existing code base to do this- I am still tracing out the execution paths between the interpreter and the f_function_constructor and the functions module as well as looking at what the AST generation and code generation does.

I am wondering if it would make sense to try to make function pointers persist and save like other types of data in lpc. I am not entirely sure how to go about this after looking at the code- but it would seem to be possible in almost all if not all cases. The main issue is that the object file might become out of sync with the program file and make no sense when calling the lfun index or offset or in the case of efuns or simul efuns if the driver or simul efun object is updated. There are currently 5 types of function pointers defined in lpc excluding the bindable flags. This also seems like a lot in modern times since I dont think the efficiency gains in terms of having bare function pointers to lfuns and efuns/simuls offer much in terms of performance savings. Would it make sense to more or less merge all these into a single case?

Well I have been looking over the source code of v8. It is quite a bit cleaner than the code in the fluffos vm. I think the main issue of patching another vm is that the fluffos has semantically some unique features that need to be carefully mapped onto other language vm's that lack those features. Some that come to mind include:

1) Dynamic class replacement. Code in fluffos has versions but the main name of a "class" or program is replaced by another object at runtime. This is a feature that most other vm's lack and needs to be mapped carefully onto another vm be it a js (v8)or lua vm.

2) Related to 1) is call other which isn't a simple function call but in most languages a reflective call lookup and call (in java).  It's more dynamic than virtual functions in most languages C/C++ java smalltalk. I have been struggling with efficient ways to implement this and get rid of boxing in lpc. I think it's a difficult problem that might not be worth the investment in time to get right because I think LPC doesnt need to be that efficient since most people are mostly running legacy applications on it.

3) OS type features- various applies are needed to be called in certain cases when certain efuns are executed. So, in general one needs to wrap function calls with extra code for this (could just be a wrapper function). Stack depth
and too long execution checks means that at the very least call_other and other function calls and back branches need extra book keeping to prevent things from running for too long. Arguably one could use some kind of time slicing like one gets in a modern operating system but the implementation work on top of what exists already is substantial.

4) inline caching. Call_other inline caching because of how it works wouldnt be mapping propery onto another vm in general. I.e. there would still be a substantial performance hit with any function call made in objects. This obviously is a general problem with OO languages and self modifying code via caching is generally used to mitigate the cost. Using anything other than a custom vm won't be able to handle this if it is ever implemented. LLvm supports patchpoint sort of which can be used to implement this. It's an experimental feature in llvm hence the sort of.

I think in general be it working on a JIT or remapping the existing semantics onto something else the development effort is nontrivial for replacing the vm wholesale. I am uncertain about what would be gained either since very few new projects are written in LPC nowadays and it's mostly legacy apps.  Writing the compiler mapping to account for the above would mean pretty much a full compiler pass upto the IL level like is current to do the language translation. The backend would obviously be the new vm.

As for a mark and sweep garbage collector- I think this is less difficult than it seems since LPC is already ref counted so their exists hooks for the creation and destruction of variables already. Obviously the destruction ones can be removed and the creation ones augmented or modified to handle the extra book keeping required in most cases. However I do wonder if mark/sweep is the best solution here since fragmentation is not addressed. I am curious in your opinion if there is any big deficiency in allocating two large blocks of memory (or a number of big blocks anyhow)- and using some sort of compacting garbage collection scheme like semi-space collection or generational garbage collection.

I was looking at the object hash tables but I haven't yet identified where the living hash lives. I found the otable.cc which houses the primary string name -> object translation. This seems pretty modular and I suspect that rewriting it to use stl instead of a custom hash table and linked list should be relatively easy.

One question I do have is- how C++ like can new code contributions be? I noticed that the modified call_out.cc still is written with primarily a C style interface and no classes or methods.

I have been thinking about experimenting with some driver hacking are contributions being accepted into the driver?