Re: The status of JIT compiler of Guile

[Nala Ginrut]

Hi Andy!
Sorry for late replay, it seems I've filtered your mail to another TAG
in my mailbox.


On Thu, Mar 2, 2017 at 4:31 PM, Andy Wingo <address@hidden> wrote:
> Heya Nala :-)
>
> And hello Atsuro!  I don't think I have had the chance of expressing to
> you how impressive your work is.  Awesome stuff!!!
>
> What do you all think is the way forward for this work?  Is it something
> that you see being integrated eventually into Guile git?  Is it a
> project that should be maintained separately?  If the latter, what
> interfaces do you need from Guile?

I'm not going to fork Guile and maintain it separately.
What I concern is if the current design is suitable to integrate
directly. And the origianl
repo can't be compiled in my machine. So I'm trying to rebase with the
latest master and
research Atsuro's paper. The point is that after ICFP meeting, no one
have tried it successfully.
Then I choose to fix it to work.

I've discussed with @Ludo, I think it's better to integrate it as a
plugin, and could be maintained separately.
It is possible to have some hooks in Guile VM to enable certain
optimizing, but I don't think we have it now, right?

it's just my idea. It's possible to integrate it directly, since it's
working with the latest Guile smoothly.
But there maybe some trivial issues need to be tweaked.

Another pointer I have to mention is that I'm not sure if the tracing
JIT concerned delimited-continuation capturing properly.
This is one of the questions on the meeting, and Atsuro said he has no
idea about that issue. That's another reason I prefer
to do some research before any conclusion or patches.

What do you think?
Are you can't wait to integrate it at once? Or make more flexible
things in Guile VM to hold pluginable optimizing sutffs?
For me, it's fine, after all, I use it everyday now. ;-P


> I think this test is a bignum/allocation test, not a compiler test.
> Still, good to see some results.

Yes it is, I just want to show something. Unfortunately, I'm not good
at benchmark. ;-)

> Andy