[Prev][Next][Index][Thread]

Re: Assorted C-FFI goodies

Nolan Darilek <nolan@ethereal.dhis.org> wrote:
> Also, I've never worked on code to communicate between languages
> before, so I'm curious about something. How, exactly, does one coerce
> C primitives into Dylan objects? I guess I could see how it is
> possible with pointers; just copy the bytes using the above function
> and structure them into an integer, right? Or, is there more than
> that? How does one do that with values as opposed to references,
> though? Is 'define C-subtype' the macro which I'd use for this? Or are
> the primitives handled in a different manner?

Non-pointer value types are converted to and from Dylan value types
(either <integer> or <machine-word>; see table 1.1 in the C-FFI
documentation) whenever they are imported or exported.

For object types, the C-subtype-definer macro allows Dylan types to be
defined that serve as designator classes, proxies for corresponding C
types.  Designator class objects are like <class> objects, except that
they contain some additional information (import type, export type,
import function, export function, pointer type, and referenced type).

In fact, the C-struct-definer, C-union-definer, C-subtype-definer,
C-mapped-subtype-definer, and C-pointer-type-definer macros can all be
defined in terms of a hook into the compiler that might be called
designator-class-definer.  This would define a new designator
metaclass object, giving the compiler enough information to do it's
job.

> Also, how would function calls work?

C function calls can be implemented using the call-out primitive,
exported from the System module of the Dylan library.  This can be
used to call specific functions, or to call through function pointers.

> And, having admitted that I've never done something like this before,
> I'm curious -- is this something that I could probably finish, or does
> a project like this require lots of knowledge about the inner workings
> of C primitives and such? I'd very much like to finish this since I'm
> extremely interested in using Dylan for regular projects, but if this
> is more than likely beyond my abilities, then I should probably shift
> my efforts to Pidgin and wait for someone else to take up
> c-ffi. Thoughts?

The C-FFI library itself is just the tip of the iceberg, an extension
of the real mechanism that needs to be buried inside the compiler.
Once the compiler machinery is in place the rest of the library should
fall into place pretty quickly.

Unless you've experienced working with the innards of compilers I
would recommend not opening this particular can of worms.  Pidgin
would be a much easier project to deal with, especially since you can
use Functional Developer to test it on.

I started working on building the compiler infrastructure required for
supporting C-FFI while vacationing at my in-laws' in Taiwan last
April.  Since I was using a laptop with a tiny screen and 64M of RAM
(not enough to recompile d2c in a timely manner) in two weeks of work
I only managed to push the requisite informaton about one third of the
way through the compiler.

I think this compiler (d2c) is a bit too complex for its own good.  I
have hopes for designing a more elegant one in connection with my
graduate research in the next couple of years.  Before that happens,
though, I've decided to go ahead and finish the
<designator-class>/C-FFI work.  So don't sweat C-FFI for now.

By the way, I'll start a CVS branch and put what I've done so far in
it, but don't expect it to be able to compile it for awhile yet.

Cheers,
-Peter S. Housel-   housel@acm.org  http://members.home.com/housel/