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 ... 3 4 [5] 6 7 ... 14
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.

Drivers / Re: WIP: Fluffos 3.0 Alpha 9.0
« on: October 08, 2015, 10:10:02 AM »
How is it possible to see what information coverity is generating for fluffos on GitHub?

Drivers / Re: WIP: Fluffos 3.0 Alpha 9.0
« on: October 07, 2015, 04:42:09 PM »
I  guess the difficulty of removing either of them is that it now breaks compatibility with a number of existing mudlibs. Has the malloc memory allocator simplification happened? Can we still use multiple different mallocs or are we down to one?

Drivers / Re: WIP: Fluffos 3.0 Alpha 9.0
« on: October 05, 2015, 09:45:09 AM »
I was trying to test the latest alpha driver under debian against the latest fluffos release but ran into a problem when it came to understanding some of the new options in the new local options. Is there still a way to make array a reserved word since ds and nightmare libs use this keyword quite a bit.

Thanks in advance

Drivers / Re: Flffos 3.0 alpha8.0
« on: April 25, 2015, 05:32:40 PM »
I just untarred the new alpha but I am having some difficulties with configure under fedora 21. It seems to be unable to locate libevent even though I have installed the package  and the header files are already in /usr/include and the library in /usr/lib64. I tried using the --with-libevent but this doesnt seem to work either.

Thanks in advance,


Drivers / Re: Difficulties compiling 2.27 under OS X
« on: October 26, 2014, 08:23:50 AM »
Thanks. It compiled but I haven't tested it yet(I made some other modifications to get it to compile one of which I am unsure of). I have been thinking of avoiding 3.0 because it is still in alpha. I was originally thinking of waiting until it reached gamma before switching and see what has changed.

Drivers / Re: Difficulties compiling 2.27 under OS X
« on: October 23, 2014, 01:19:28 PM »
I get the following error during the link phase. I am not sure if I need to somehow find a way to locate libconv. I tried installing a new version of libconv with macports but this didn't do anything.:

gcc -std=c99 -D_GNU_SOURCE -m64 -flto -D__USE_FIXED_PROTOTYPES__ -O3 obj/ obj/lex.o obj/main.o obj/rc.o obj/interpret.o obj/simulate.o obj/file.o obj/object.o obj/backend.o obj/array.o obj/mapping.o obj/comm.o obj/ed.o obj/regexp.o obj/buffer.o obj/crc32.o obj/malloc.o obj/mallocwrapper.o obj/class.o obj/efuns_main.o obj/efuns_port.o obj/call_out.o obj/otable.o obj/dumpstat.o obj/stralloc.o obj/hash.o obj/port.o obj/reclaim.o obj/parse.o obj/simul_efun.o obj/sprintf.o obj/program.o obj/compiler.o obj/avltree.o obj/icode.o obj/trees.o obj/generate.o obj/scratchpad.o obj/socket_efuns.o obj/socket_ctrl.o obj/qsort.o obj/eoperators.o obj/socket_err.o obj/md.o obj/disassembler.o obj/uvalarm.o obj/replace_program.o obj/master.o obj/function.o obj/debug.o obj/crypt.o obj/applies_table.o obj/add_action.o obj/eval.o obj/fliconv.o obj/console.o obj/posix_timers.o `./dtrace_compile` -o driver packages/packages.a  `cat system_libs`
undef: _iconv
undef: _iconv_open
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      _translate in fliconv.o
  "_iconv_open", referenced from:
      _get_translator in fliconv.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [driver] Error 1
make: *** [main_build] Error 2

Drivers / Difficulties compiling 2.27 under OS X
« on: October 21, 2014, 11:19:18 AM »
I am having some difficulties getting fluffos to compile under OS X 10.10 Yosemite. There is a type error in the interpret.c code with LPC_INT and long being type incompatible and also a problem with posix timers since OS X doesnt have these (there is a problem with time_h not being defined out in the posix_timers.c). The last hurdle I have encountered is that libiconv isnt linking properly. Is there an older version of comm.c that lacks the fliconv hooks? Will the code work if I strip out the translate and get_translator calls?

Thanks in advance,

P.S. unfortunately my linux laptop died on me so I am not forced to use the mac for compiling fluff.

Drivers / Re: Status update of fluffos 3.0
« on: October 17, 2014, 08:29:39 PM »
Would it be possible to have the reserve block play nice with STL containers? I think if this change were made it would allow for simplification of a lot of the code in the driver. I haven't really thought about this but I am thinking it would require perhaps as little a change as just adding a custom STL allocator.

This would allow for some obvious simplifications of various tables callouts, object table and uids. This would mean one could also remove avltree.

Drivers / Re: smart pointers as a change to the driver for refcounting
« on: October 15, 2014, 06:30:39 AM »
I guess it does call into question why some of the older memory optimizations are still needed. Perhaps the best solution rather than implementing something new like a gc would be to get rid of the older memory allocators and just use system alloc. STL isn't really compatible with them or the DXMALLOC macro. How many users do you have on at maximum?

Drivers / Re: smart pointers as a change to the driver for refcounting
« on: October 14, 2014, 10:21:12 PM »
I think writing one's own language from the ground up is even more work than doing a retrofit. I believe it took Dworkin around two years to get a ground up rewrite of a driver working. I still think the complexity is being overestimated. It's not easy but I don't think it's that difficult either. Adding something like boehm gc is trivial. I think I did the same thing out of interest at one point many years ago- but given how boehm gc works you cannot guarantee unlike a custom gc that all the ram is freed properly. I dont think it much matters either since if the code doesnt work no one needs to use it. I suspect however it would make making other changes to the driver easier if one did modernize the driver some and since the driver has moved to C++ I think it would make some sense to exploit some of the features. One of the hurdles here is that the global memory management of the fluffos driver via C malloc macros makes it difficult to use the C++ style new and delete operators.

I think using classes and stl would vastly simplify a lot of the code. Perhaps it might be better if I did this with ldmud since it's a bit cleaner but I am more familiar with the mudos/fluffos line.

Drivers / Re: smart pointers as a change to the driver for refcounting
« on: October 14, 2014, 05:31:06 AM »
If you are referring to the boehm garbage collector, it is actually less than ideal since it has to guess which entities in the code are pointers. Boehm gc is thus known to leak memory. The main shortcoming of a garbage collector over a ref counting implementation is that memory isn't freed immediately when data stops being referenced and there may be a significant pause in a simple stop the world implementation.

The problem with ref counting is it is imperfect for something like a mud since one can get circular reference garbage. Also it is error prone since I seem to recall Wodan some years ago indicating that fluffos leaks ram and was unable to track the cause. So the problem is that there might be errors in the existing code.

Pages: 1 ... 3 4 [5] 6 7 ... 14