There is an intermediate method, have our own execution and data stack.
Basically build a TIL interpreter. This might be intermediate in speed
between raw machine code and the perl vararg calls.
If not intermediate in speed, I suspect it would involve cleaner
looking code. All functions would look the same all calls between
internal functions would look the same.
<chaim>
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Do you need this "deep carnal knowledge" to make it efficient, or just to
>> make the thing fly at all?
DS> Depends on how we implement the thing.
DS> If we build up real function code at runtime, we can encapsulate all the
DS> state we need in a single function pointer, and don't need to have the
DS> caller pass in any state at all. This is good, since it means the caller
DS> can do:
DS> (*foo)(1, 2, 3)
DS> to call the perl sub whose function poiner's stored in foo. (Well, assuming
DS> I got the syntax right) The bad thing is we need to know how to generate
DS> the function header and whatever bits we need to have to pull arguments off
DS> the stack and out of registers and turn 'em into perl PMCs, then call the
DS> real perl code.
DS> The alternate method is to use something like we've got now with the
DS> perl_call_* stuff, where you pass in a pointer to the real perl function to
DS> a generic (vararg'd) C function, like:
DS> perl_call(perl_cv_ptr, 1, 2, 3);
DS> the bad bit about that is it means that calls to perl functions are
DS> different than calls to C functions, and I'm trying not to do that--I
DS> really do want to be able to get real function pointers that can be used in
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
