[DGD] LLVM dgd side project

[Carter Cheng]

Actually I have been mostly working in the direction of 2) over one in the
past. There are still some details for me to work out that are in some
cases not unique to 2). One area that is still tentative is coping with
atomic/rlimit/catch blocks. My first thought is that it can be implemented
in LLVM by making the blocks separate nameless functions that are scoped to
within the original dgd function. The idea is to use LLVM exceptions to
cope with when the atomic/rlimit/cache terminates due to an error. I need
to do a bit more research into this to check it's a valid approach.

On Fri, Mar 31, 2017 at 2:04 PM, Felix A. Croes <felix at dworkin.nl> wrote:

> 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?
>
> Swapfile compatibility is irrelevant, snapshot compatibility is very
> important.  Option 2 is to be preferred, but if you choose option 1 to
> get started, it would certainly be a useful contribution.
>
> Regards,
> Felix Croes
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd