[DGD] question about I_SWITCH

[Carter Cheng]

Thanks Felix. I will need to think about I_CATCH and I_RLIMITS some
more. I am currently thinking that perhaps noting the basic block
context and replacing the I_RETURN with a jump to the end of the basic
block (hence returning out of the embedded block representing the
recursion) might be a workable approach by having a stack of pointers
to the embedded blocks.

I should perhaps have a working prototype soon once I get I_SWITCH
implemented and something which replaces the builtin kernel calls with
appropriate operations in the bitcode/function calls. I will probably
keep going at this today. The grunt work probably will be in the kfun
replacing atm.


On Sat, Jun 26, 2010 at 8:52 PM, Felix A. Croes <felix at dworkin.nl> wrote:
> Carter Cheng <cartercheng at gmail.com> wrote:
>
>> I have been working on a prototype for the JIT for dgd-osr but ran
>> into a few issues with some of the opcodes that I am still trying to
>> resolve. In particular I_SWITCH does not translate well into LLVM
>> bitcode since a function that returns a program counter is not useful
>> in this context. I am curious if this data can be decoded internally
>> by the interpreter and converted into a series of jumps (or if this
>> could be done by the dgd compiler).
>
> Well, of course the interpreter already decodes I_SWITCH internally,
> so anything it does you can replicate.  You should think of I_SWITCH
> as a type of jumptable, which can of course be converted.
>
>
>> The other two opcodes I am having some problems with are I_CATCH and
>> I_RLIMITS. These two seem to recusrively call i_interpret and I cannot
>> really do this in llvm. I suspect the correct strategy is to replace
>> this recursive call with a series of basic blocks with an exception
>> block in the case of I_CATCH and work with compiling perhaps two
>> versions of every function at some point one with rlimit type counters
>> and one without.
>
> These can also be converted, but there is one thing you have to take
> into account: an I_RETURN instruction can return from a function, but
> also from a I_CATCH or I_RLIMITS recursive call.  What your code should
> do is keep track of the current context, and perform the appropriate
> task.  You can do that at JIT compile time; the possible meanings of
> I_RETURN do not overlap for any instance of the instruction in the
> code.
>
> Regards,
> Felix Croes
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>