[Pdx-pm] Designing a C library specifically for HLL binding

[Eric Wilhelm]

# from chromatic
# on Thursday 30 October 2008 13:30:

>> The HLL
>> binding would then be doing all of the memory allocation (part of
>> the plan being to minimize the memory footprint, but also to make a
>> 'Perlish' API.)
>
>This makes the HLL binding do a lot more work.

That's actually part of the plan.  Given that making a perlish API for 
any non-trivial data requires some manipulation of HV's and AV's 
(aka "a lot of work"), and that I have to write everything from a blank 
slate, I was figuring on keeping the shared library rather dumb.

>It has to know how 
> much memory to allocate (which can vary from platform to platform),

The goal there was "none".  The temporary structs are lexically scoped 
by the caller (this is called an "automatic variable"?) and pointers to 
them are passed into the shared functions, so nothing in the shared 
library deals with memory.

  // in sharedthingy.h
  struct pointstruct {
    float x;
    float y;
    float z;
  };

  // in Inline::C code:
  SV* next_polygon(SV* obj) {
    filedatastruct* fds = (filedatastruct*) SvIV(SvRV(obj));
    ...
    HV * hash = newHV();
    int i;
    int p;
    pointstruct * a_point;
    ...
    p = get_polygon_point_count(fds);
    for(i=0; i<p; i++) {
      ...
      get_polygon_point(fds, i, a_point);
      ... hand-waving about the array of arrays for now ...
      av_push(pt, newSVnv(a_point->x);
      av_push(pt, newSVnv(a_point->y);
      av_push(pt, newSVnv(a_point->z);
    ...
    return(newRV_noinc((SV*) hash));
  }

At least, that's what I have in my head thus far.  Am I correct in my 
reading that there's nothing to malloc/free here outside of what the 
perlapi calls are doing for me?

> so you'll end up recompiling the HLL binding every time the shared
> library changes.

Assuming that I *want* some part of this to be in XS, you have to do 
that anyway, right?

At least, I think I want the loop over e.g. get_polygon_point() to be 
happining in the XS.  Meaning, that for e.g. 1000 polygons you would 
have 4000+ function calls between the XS and C code but only 1000 calls 
to the XS function (each of these returns a hash reference such as
"{points => [[$x0,$y0],[$x1,$y1],[$x2,$y2]], color => 0xFF0000, ...}".)

The alternative seems to be writing a lot of repetitive perl code, or a 
lot of C code which deals with memory management which will have to 
then be done over again in XS to get a binding.  So, I'm thinking there 
would be no next_polygon() function in the shared library.

This would mean that the low-level stuff in the shared library could 
stick to just dealing with the bitwise twiddly stuff, while the binding 
would mostly deal with assembling Perl data structures and error 
handling.

Now of course this assumes that the interpreter is implemented in C.  
What would something like this mean in parrot?

Thanks,
Eric
-- 
"Everything should be made as simple as possible, but no simpler."
--Albert Einstein
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------