Re: [Caml-list] calling native code from bytecode?

[Chris Hecker <checker@d6.com>]

Just a couple clarification questions (in case I decide to try to hack a prototype of this into the compiler):

>One solution would be to have two code pointers per closure, one
>bytecode and one native-code.

I think, if I was just trying to do leaf functions (that don't take closures as parms) in native code to start with, that I'd just make another bytecode instruction for native calls.  Having two pointers does seem like it'd be better if you were trying the complete solution, but I think you're right that it would be hard to implement.  It seems like the OC_CALL* instruction could mostly mirror the implementation of C_CALL* up to the point of call, because currying and whatnot would work the same way.

So, just to be excruciatingly clear, assuming there are no closures in any of the parameters to a function call, the "values" passed in and any native code and GC operations on those values are completely compatible?  Even for arbitrarily complex datastructures, as long as no closures are in the mix?

If I constrained the problem to just leaf functions (where leaf is defined as never calling back into bytecode) then it would work, runtime library-wise?

I wonder if there would be issues between the standard library functions that are implemented in C, although I'd assume they'd link, would there be sync issues?

I assume threads would be a mess, too, so I'd disable them as well.

Since bytecode and native code both use .cmi files, I assume module structure and signature layouts are compatible?

>> I suppose I could do some sort of heinous bytecode -> C ->
>> native code shim
>Besides problems with potential callbacks from native-code to
>bytecode, there are also (non-essential, but intricate) GC issues that
>would come in the way.

You mean for the shim solution in that sentence, not if I was just passing values straight to the native code?

Thanks,
Chris


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr