[DGD] LLVM dgd side project

[Raymond Jennings]

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