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

Re: Assorted C-FFI goodies

>>>>> "Peter" == Peter S Housel <housel@acm.org> writes:

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

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

Hmm, now I'm curious. :)

I've been toying with call-out now that I've discovered it. What
components of c-ffi need to be buried in the compiler?

In studying the specification a bit more closely, I began to determine
that I'm not interested in a full and complete c-ffi implementation at
the moment. Unless I'm mistaken, the complete definition allows for
Dylan functions to be called from C, which I'm not particularly
interested in at the moment. If I sacrifice that functionality, then
how difficult would it be to achieve access to C data from within
Dylan? With call-out, is it possible to implement a Dylan function
which simply runs call-out on the results of a macro call and returns
the result variable? What about access to C variables? Would the
c-decl macros within the System module be useful for this? Or am I
missing something important?

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

Ah, heh. I just grabbed another 128 megs of RAM; the 64 meg situation
was killing me until last Friday. Hence my sudden drastic increase in
activity and interest. :)

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

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

That'd be awesome! If this is as difficult as it is then I'm not sure
if I can help, but I'd be interested in seeing if I'm on the right
track with this. All I've had to go on for the past few days is the
warning/error ratio which I'm slowly decreasing, but I could be
completely botching everything. I tried writing my first memory
address and bit manipulation functions today, and probably did them
completely wrong considering that everything I learned about those two
subjects was gleamed from a casual glance over the d2c/runtime/dylan
sources. :)
Follow-Ups: