[DGD] LLVM dgd side project

[Carter Cheng]

Thanks Raymond anyhow.

On Sat, Apr 1, 2017 at 3:35 AM, Raymond Jennings <shentino at gmail.com> wrote:

> Assuming you mean snapshot compatibility, that is critical to be able
> to port a mud from DGD to LLVM.  At the very least you'll need to
> study the source code to understand the data format.
>
> If you're interested in swapping (no pun intended) between drivers,
> you have to be aware of:
>
> 1.  If you move from LLVM, the standard DGD will still need its own
> native bytecode to execute.  If you don't generate DGD bytecode at
> compile time, that will be impossible.
>
> 2.  Importing a snapshot that only has DGD bytecode will need
> translation of that bytecode.  Some of which will be stuck in use as
> it will be part of whatever infrastructure is required to tell LLVM to
> compile.  Whatever executes the compile_object kfun under LLVM itself
> will be in DGD bytecode if you arent't starting out with an LLVM based
> cold boot.  Unless you start with LLVM on cold boot time, it is
> impossible to generate LLVM bytecode without first going through DGD
> bytecode.
>
> Compiling to DGD bytecode from LPC source, and then from DGD bytecode
> to LLVM bytecode, is similiar to the process discussed with JIT
> support, and it is the only safe way (that I know of) to retain
> compatibility without a cold boot.
>
> ----
>
> Apparently this message got stuck in my outbox and felix pretty much
> covered it already by the time I noticed.
>
> Just remember that if you're transitioning between the two during a
> mud's virtual uptime then DGD bytecode has to be preserved due to the
> decoupling between reboots and LPC compilations.
>
> On Thu, Mar 30, 2017 at 3:45 PM, Carter Cheng <cartercheng at gmail.com>
> wrote:
> > I am currently examining the possibility of modifying the current vm to
> run
> > instead on top of the llvm infrastructure. I am curious if I happen to
> > manage this whether something like this would be accepted into the main
> > distribution. Basically to get this to work there are two possiblities
> >
> > 1) Compile directly to llvm bitcode in comp/codegen.
> >
> > 2) Mirror some of the existing control block structure in a volatile
> cache
> > that gets updated when something compiles or when control blocks load
> from
> > disk and convert the bytecode on the fly into llvm bitcode.
> >
> > I am not particularly partial to either solution. 2) is messier but
> retains
> > swap file compatibility while 1) breaks it. Is there some reason I might
> > prefer one to the other? How important is swapfile compatibility?
> >
> > Regards,
> >
> > Silenus
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd