Re: guile-vm 0.3

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> I don't know, if you feel like it, you can try to go along with the
> things that I have done for the i386 and try them out on the PPC.

For the past couple of days, I've had a half-formulated idea running
around in my head.  I've been thinking about g-wrap, lightning,
libfcall, and libffi, and trying to figure out whether or not it might
be possible (and both reasonbly efficient and sufficiently portable)
to add some instructions to lightning that would allow on-the-fly
wrapping of C interfaces.

As it stands, g-wrap, given a spec file, dumps C wrappers
automatically to a .c file.  For a large number of wrapped C
functions, this file can become quite large. so generating the wrapper
code as-needed could be advantageous, if it's not too expensive.

Further, with every call of a C-side function, the g-wrap wrappers
carefully check their arguments, but in cases where you have something
like this at the scheme level (presume all the functions called here
are g-wrapped C functions):

   (let ((foo-obj (make-some-C-obj-ptr-of-type-foo x y z)))
     (foo-frob! foo)
     (foo-bar! foo)
     (foo-baz! foo)
     (foo-whatever foo)
     foo)

there is *no* need to check the arguments to any of the function calls
since you know from the g-wrap prototype that the "make" function can
only return a foo ptr.  So if the machine glue to call the C functions
was being generated at run-time (or at guile compile time), these
checks could be omitted for a substantial performance advantage,
especially in tight loops.

Another way to accomplish this would be to have g-wrap generate
checking and non-checking versions of all the functions and then just
call the right ones at the right times, but this would add more bloat,
and I thought the JIT/ffi/whatever solution was worth at least
considering for a moment.

I presume that for this to work, lightning would either have to have
instructions for performing the conversions, and the equivalent of a
c-side C "apply", or alternately, we'd need to integrate with
libffi/libfcall or similar.

The downside is that having g-wrap generate C wrapper code is
extremely portable, and one of these fancier solutions might be less
portable, unless we were willing to commit to keeping the
infrastructure working everywhere.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930