On Jan 28, 2011, at 09:33, Noah Lavine wrote:
>
>> And also... why not rely on gcc's tail-call optimization, in the case
>> where it works? You can check for it at configure-time. I just ran
>> some small tests for tail-calls between functions in separate
>> compilation units and it shows that i
Hi,
On Fri 28 Jan 2011 15:33, Noah Lavine writes:
>> And also... why not rely on gcc's tail-call optimization, in the case
>> where it works? You can check for it at configure-time. I just ran
>> some small tests for tail-calls between functions in separate
>> compilation units and it shows th
Him
>> Therefore, I think the path to a native-code VM is to leave the VM as
>> it is (except maybe reserve an opcode for native-code calls). Then I
>> write first a C parser for Guile and then a converter program that
>> would take Guile's current VM and output a JIT VM like I've described.
>
> H
Heya Noah,
Replying out-of-order here.
On Sat 08 Jan 2011 18:27, Noah Lavine writes:
> Therefore, I think the path to a native-code VM is to leave the VM as
> it is (except maybe reserve an opcode for native-code calls). Then I
> write first a C parser for Guile and then a converter program tha
Hello all,
Sorry for all of the discussion about native code generation. I have
another idea for how we could implement a good interface to JITed
code. I've actually been thinking it for a while and initially
dismissed it as too crazy, but now I'd like to see what you all think.
The issue this so
