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] 4 5 ... 11
31
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).



 

32
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?

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

34
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?

35
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?

36
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

37
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,

Silenus.

38
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.

39
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/grammar.tab.o 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

40
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.

41
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.

42
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?

43
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.

44
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.

45
Drivers / Re: smart pointers as a change to the driver for refcounting
« on: October 13, 2014, 04:23:37 PM »
I think the main concern with the refcounting in the driver is it is known to leak memory even without the cycle issue.  I am not saying a gc is easy but i think it isn't that hard either. The algorithm for the simpler variants isn't too complex (especially mark and sweep). There is some additional overhead unless one reimplements the malloc free code one needs additional pointers and a free pointer list.

Ref counting seems simpler but I worry that the current manual bumping of pointer refs which occurs in many places in the code is both not particularly modular and error prone- hence I suggested using shared pointers instead and automating the ref bumping.

Pages: 1 2 [3] 4 5 ... 11