Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
Dan Sugalski wrote: If there's no hit, I'd love to have all perl functions callable from outside. I'm not sure that'll be the case, though I'm all for it... With the 334 infrastructure, the -o option to generate a linkable object from a perl program/library (RFC 121) will be most do-able: "specially attributed" functions get put in the .h file and linker symbol table, and normal functions still require conversion to/from PerlData before calling. It would be nice to add as much automatic conversion as possible based on information in prototypes. A C++ programmer could define some conversions from the types in their strongly typed compiled type system to the PerlData types, for instance. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "After jotting these points down, we felt better."
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
At 06:30 PM 10/10/00 -0400, John Porter wrote: Dan Sugalski wrote: Perl functions that are called from outside will have to have some sort of interpreter attached to 'em. I can see either a default interpreter, or the one they were compiled into being valid as a choice. If there's no hit, I'd love to have all perl functions callable from outside. I'm not sure that'll be the case, though I'm all for it... As you say, it's a matter of providing context. For some categories of functions, the only context necessary will be an interpreter handle. For other, presumably lower-level, functions, other gobs of context will be needed. If it will be possible to encapsulate that other context stuff into a ball, then presumably a handle to that ball can be handed to the calling program, for use in future calls. But that may be a big "if"... It may be a huge and insurmountable "if". It may even require the caller to do some sort of semi-global setup or something. (PERL_SET_CONTEXT, say) It may turn out that the context required to function will make this proposal infeasable, though I hope not. (Might be tricky when using it with multiple active interpreters, but I bet we can do it in the single-interpreter case at least) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
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: DSperl_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 FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
At 01:50 PM 10/10/00 -0400, Chaim Frenkel wrote: 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. Perl functions that are called from outside will have to have some sort of interpreter attached to 'em. I can see either a default interpreter, or the one they were compiled into being valid as a choice. 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. If there's no hit, I'd love to have all perl functions callable from outside. I'm not sure that'll be the case, though I'm all for it... "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: DSperl_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 FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 01:50 PM 10/10/00 -0400, Chaim Frenkel wrote: 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. DS Perl functions that are called from outside will have to have some DS sort of interpreter attached to 'em. I can see either a default DS interpreter, or the one they were compiled into being valid as a DS choice. Hmm, I was probably off base. I was thinking of multiple implementations of the runops methodology. Not of how to call into perl only between perl funcs. If at all possible there should be only one way to write the function and one way to call it. So that the innards can be independent of the actual implementation. A Calling from the outside should be extremely limited. One shouldnt' be allowed to straddle the fence. 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. DS If there's no hit, I'd love to have all perl functions callable from DS outside. I'm not sure that'll be the case, though I'm all for it... I don't think you want that. Calling a perlop directly has to mean that the caller is signing in blood that there are no guarentees of when it would break. We might want someone peeking behind the curtain to supply an expected version, and we could either accomadate it or break it early enough to give sufficient time to adjust the code. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
On Fri, Sep 29, 2000 at 12:37:15PM -0400, Dan Sugalski wrote: At 04:13 PM 9/29/00 +0100, Nicholas Clark wrote: Are you suggesting that the attributes use the same mapping system as the XS (or son-of-XS (XS++)) typemaps in lib/ExtUtils/typemap? If so, will there be the "terse" column in the typemap file to associate "i" with "T_IV" ? Hadn't considered it, but my first thought is to not shoot for that as a target. The code that takes the parameters from the C-level calling frame and builds PMCs out of them will be operating at a very low level, with deep carnal knowledge of a platform/processor pair's calling sequence. It's going to have to know the order that things go in registers, which registers hold which types of parameters, and how excess parameters flow on to the stack (or wherever they go) This is code that'll be different (potentially) for every operating system on every processor perl runs (and supports this) and I don't know that we can get this flexible. 'Specially since many of the conversion routines will have to be written in C, rather than in perl. (If perl gets a pointer to an array of char pointers, what exactly could it do with it?) Do you need this "deep carnal knowledge" to make it efficient, or just to make the thing fly at all? If the former, does that mean that you're thinking of having a generic C approach that will work on anything, but probably not very fast, coupled with custom code generators for platforms people know about and work on [so VMS will have good support on this one :-)] ? If the latter, if only VMS, x86 BSD and x86 Linux (and probably Solaris 9) have support, what is everyone else going to do if they are attempting to compile some or other third party app that needs this feature? Nicholas Clark
