At 08:50 PM 9/29/00 +0100, Nicholas Clark wrote:
>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?
Depends on how we implement the thing.
If we build up real function code at runtime, we can encapsulate all the
state we need in a single function pointer, and don't need to have the
caller pass in any state at all. This is good, since it means the caller
can do:
(*foo)(1, 2, 3)
to call the perl sub whose function poiner's stored in foo. (Well, assuming
I got the syntax right) The bad thing is we need to know how to generate
the function header and whatever bits we need to have to pull arguments off
the stack and out of registers and turn 'em into perl PMCs, then call the
real perl code.
The alternate method is to use something like we've got now with the
perl_call_* stuff, where you pass in a pointer to the real perl function to
a generic (vararg'd) C function, like:
perl_call(perl_cv_ptr, 1, 2, 3);
the bad bit about that is it means that calls to perl functions are
different than calls to C functions, and I'm trying not to do that--I
really do want to be able to get real function pointers that can be used in
C code just like any other C function.
>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?
Well, perl will provide this, so whoever's doing the port for a platform
would have to provide this in the platform-specific code. I doubt it's
changed for Solaris on SPARC since, the SunOS 4.x days, I know it's not
changed for OpenVMS Vax for ages and hasn't changed at all for OpenVMS
Alpha. Other platforms are likely similar--this is the sort of thing you
really can't mess with, since it breaks backwards compatibility in many
profound and nasty ways.
That doesn't mean it's going to be *easy*, mind, but certainly doable.
Whether it's a reasonable thing is a separate question, of course.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
