|From:||Stefan Israelsson Tampe|
|Subject:||Re: patching gcc to allow other calling conventions|
|Date:||Thu, 21 Jun 2012 14:32:12 +0200|
A JIT would be a good thing for Guile to have. I worked on a JIT a
> But the used sbcl derivative although not gnu is either in the public domain
> or bsd so we should be able to publish what we are doing. I prefere now to
> start working on a simple jit scheme for the fun of it, because it is a good
> learning experience and that getting results are a good driver to continueu.
while ago, and I found that the hard part was not generating machine
code or connecting it to the VM - both of which it looks like you've
done - but making the JIT engine understand all of the VM
instructions. You could just hard-code them all, but then you've got a
complete duplicate of vm-engine.c with exactly the same information,
but in different syntax. So I thought I wanted some way to generate
the JIT from vm-engine.c, but that requires parsing C code. That's a
capability I want Guile to have in general, but I haven't made it
What do you think about this? Would you just want to maintain the JIT
engine separately from vm-engine.c, or would you like to automatically
(Note: you could also generate vm-engine.c and your JIT from some
third source, but I think we rejected that for being too complicated.
It would certainly make the build process more difficult.)
> Den 18 jun 2012 02:43 skrev "Noah Lavine" <address@hidden>:
>> > Did you consider starting from GNU/MIT Scheme? It supports only IA32
>> > and x86_64, I think, but it’s in Scheme, and it’s GNU.
>> Actually, that's an interesting thought in general. I looked at MIT
>> scheme a bit a long time ago, but I believe it uses two intermediate
>> languages, a high-level one similar to Tree-IL and a low-level one
>> that I don't know much about. We might be able to turn Tree-IL into
>> the high-level one and use their compiler infrastructure. Since
>> they're a GNU project, there might not be copyright issues.
>> However, I'm not sure if this has advantages over just building it
>> ourselves. And I don't know if the MIT Scheme developers would like
>> this or not.
|[Prev in Thread]||Current Thread||[Next in Thread]|