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 - silenus

Pages: [1] 2 3 ... 10
Drivers / fluffos 2.xx line
« on: June 24, 2017, 01:28:05 PM »
I actually have already forked the fluffos 2.xx line from quix's 2.27.2 and made some minor modifications to make it compatible with freebsd and os x. This basically involved adding back some removed code when posix timers is undefed in the driver. I will try to make some more changes to this fork tomorrow by migrating the basic build script to cmake (not the edit source though). I am curious if anyone has any other suggestions for changes to the driver if I find time to implement them on weekends. Some things I have considered include rewriting the array and mapping code to use stl and possibly the string handling to rely on std::string. I think a garbage collector would also be a nice addition (this sort of exists already in ldmud). Ideally if I get everything cleaned up and sorted out Wodan might give me permission to release a 2.28 that unlike the fluffos 3 line retains compatibility with existing muds.

Intermud / i3 client code sample
« on: June 24, 2017, 01:19:38 PM »
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?

General / Re: MUD documents and webpages
« on: June 17, 2017, 06:07:32 AM »
I have a repository that has a slightly modified fluffos 2.27.2 that restores some old code to make it possible to run fluffos on os x and freebsd. See the commit log for more details of changes.

Drivers / Re: new year resolution
« on: January 09, 2016, 03:52:12 PM »
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.

Drivers / Re: new year resolution
« on: January 09, 2016, 11:18:44 AM »
Maybe changing object pointers to object handles to make it so that you dont have to do datastructure and stack scans after destructing an object?

Drivers / JIT compiler revisited for Fluffos/dgd
« on: November 05, 2015, 01:38:00 PM »
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.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 07:09:55 PM »
I was actually beginning to wonder about that after I posted that but I suspect there might be a way to have function pointer forms persist through save/restore_variable like reflection functions. The idea would be to have a function_info return a call_other representation of the function pointer including the arguments and leave it up to the user as to how to best to serialize the information. As for code I suspect that functionals don't have an object context (I don't think anonymous functions do either) so they could more or less be floating blocks of code.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 09:46:10 AM »
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.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 07:23:52 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.

As for upgrades- I know dgd currently automatically restores the data, but I wonder if another approach might be to pass the old version of the object to the new object in the upgrade() function and use some form of reflection variables(), set_variable(), fetch_variable() to get at the old data and xlate it across. This would allow for the new recompiled versions of the object to construct new lambda objects using new code making it possible to upgrade the code pointed to by the anon funcs given the old functions with perhaps the right reflection routines. If the closures hold data i.e. are collectors this might be a bit complicated though.

Drivers / function pointers and anon funcs
« on: October 31, 2015, 01:46:19 PM »
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?

Drivers / Re: Contributions to the driver
« on: October 29, 2015, 10:42:09 AM »
I think I get what you mean by bridging now but I think you are still at the mercy of certain things by doing this that developing on an lpmud server prevents.

1) malicious code execution that modifies or deletes data.
2) denial of service type code execution that deliberately starves resources via infinite loops etc.

I don't see a good way around this other than rebuilding a layer on top of whatever as I mentioned. I think also by doing this one is no longer really operating in lpc. In general this isn't necessarily a bad thing but it makes it difficult to program the system when it's running along side other users because of the two issues above.

Drivers / Re: Contributions to the driver
« on: October 29, 2015, 05:00:12 AM »
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 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 still is written with primarily a C style interface and no classes or methods.

Drivers / Re: Contributions to the driver
« on: October 26, 2015, 08:06:31 AM »
My interest primarily lies with the implementation of the vm. For example one thing I found that might be worth doing is changing the functional/function pointer code a little bit so that certain types of function pointers can be saved by save variable and restored. This would only be (of the 4 types) for lfuns.

It might also be nice if the string or func could somehow be merged into the functional syntax as well as the remaining old function pointer types- this would sort of conflict with the above though and would require some sort of general scheme for saving and parsing function pointers. I suspect this is doable with a bit more work with saving/restoring function pointer strings but would require some additional parsing routines to cope with restoring strings to functionals. This obviously is more work than the above but more general but also not that much more useful.

Another thing I would like to look at is garbage collection of the mark and sweep variety which is already used in certain memory models for ldmud. This would not solve the problem of fragmentation so I have some hesitations here too but I dont know other forms of garbage collection well enough to know how reserving large blocks of ram would affect the OS in general (this would be required for semi-space and generational collections). The algorithms in general for garbage collection in the stop the world case seem simple enough. (I actually wrote a tricolor mark/sweep in lpc for fun once where one could customized the root set and clean up objects that werent referenced by something)- most textbook descriptions are quite simple or even research papers.

Lastly I still dream of having a JIT for some version of LPC that optimizes away the cost of branch instructions in the vm for instruction selection at the very least and with llvm patchpoint perhaps includes some form of inline catching for call other instead of virtual functions. One of the biggest problems with lpc is that call-other is runtime typed as opposed to statically typed like virtual functions in C++ and java making it difficult to unbox types in sequences of instructions having calls to other objects that are not bound at compile time (inheritables are bound at compile time and dont change so  these are okay).  This however is quite a bit of work though it might be fun to do.

One question I do have is how much C++ is expected to be seen in the driver in the future? There is a lot of runtime type selection in the code at present which could be replaced with virtual functions and OOAD style dynamic dispatch. The main conflicting problem in this area is that in certain cases this makes it harder to infer the actual machine code layouts for objects/programs which would make it harder to implement JIT style tricks if it is a worthwhile goal (but I am not sure much like ruby and python if one really needs that sort of performance anyhow).


Drivers / Contributions to the driver
« on: October 18, 2015, 06:33:40 PM »
I have been thinking about experimenting with some driver hacking are contributions being accepted into the driver?

Drivers / Re: WIP: Fluffos 3.0 Alpha 9.0
« on: October 10, 2015, 02:00:05 AM »
Sent you my email via pm.

Pages: [1] 2 3 ... 10