FFI syntax (was: Re: [Vm-dev] Re: testing MT and reentrant)

[Eliot Miranda]

On Thu, Mar 24, 2011 at 12:02 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 24 March 2011 19:43, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > 2011/3/24 Levente Uzonyi <leves at elte.hu>
> >>
> >>
> >> On Thu, 24 Mar 2011, Eliot Miranda wrote:
> >>
> >> (pine can't quote your mail, sorry)
> >
> > :)  No problem.
> >
> >>
> >> "I have some image-level changes that I'll try and commit asap, or at
> least give you as some inbox packages
> >> - parsing FFI method annotations to discover the #threaded keyword that
> sets the "go ahead and thread this call" bit in an FFI spec
> >> - an additional inst var in ExternalFunction (IIRC) that allows the VM
> to record how much stack space to reserve when marshalling an FFI call
> >> - the new callback marshalling machinery that provides
> platform-independence
> >>
> >> I just need to fid the time to push the code to you.
> >>
> >> Now on testing I use
> >> a) an image with a "listener" that reads and writes from/to stdin/out
> while allowing one to interact with the image
> >> b) a native Mac OS file dialog that uses a threaded call to invoke
> without blocking the image and threaded callbacks to determine which files
> to
> >> show (filter callback) and what the accept action is.  I've of course
> lost my workspace containing this and so have to ferret out the doits from
> my
> >> changes file (I feel such a fool!).  Alas this will need work as it used
> an extension to a Teleplace native file dialog plugin.  But posting it to
> >> FFI will be good; it will test the FFI further.
> >> c) a threaded version of the ODBC connect that hasn't really been tested
> >>
> >> etting you and others to start pounding on these would be fantastic.
>  Just a matter of finding time.  f you're happy for me to push inbox
> packages,
> >> changesets, workspace contents then I can provide something quickly.  If
> you want me to commit canges that I've made sure are backward compatible
> >> and don't break trunk I'm going ot be much slower.
> >>
> >> best regards (albeit feeling a little frazzled :-) ),
> >> Eliot"
> >>
> >> Isn't it the best time to migrate the syntax of FFI calls to Pragmas? I
> know it takes some time to implement the pragma support, but IIRC Lukas did
> that a few years ago, so dusting it off and adding support for threaded
> calls (which I didn't see yet) shouldn't be that hard.
> >
> +1000.
>
> > SPunds good.  Got any URLs?  Lukas, got any code?
> >
> >>
> >> Both formats could be supported for a while, then we could leave the
> current format behind and simplify the parsers/compilers, etc.
> >
> +1
>
> > Indeed.  In fact, nothing is set in stone here.  I desperately want an
> accurate C signature, not the quick hack we have now (a good thing we have a
> quick hack, but its a long way short of copy/pasting C into the pragma).
>  The interpreted marshalling scheme Andreas did (ffi specs etc) can serve
> for the moment.  The main thing before getting rid of that is a design for
> e.g. a NativeBoost based marshalling code generator that is cross-platform,
> cross-ABI and works with the interpreted VMs.  I think this is therefore a
> good way off, and there are people like Esteban who need to get going now,
> so we can't let the perfect be the enemy of the good and need to provide
> something functional asap, and that may mean living with the current ffi
> annotation for a few months.
>
> In NativeBoost i made a separate class for parsing a C function
> declaration. It supports two forms of declaration:
>  - named function, i.e.
>   int foo (int bar, float zork)
> and anonymous one:
>  int (int bar, float zork)
>
> as input, parser takes a literal array.
>
> So its quite easy to integrate it into compiler/pragma parser, we only
> need to find out what format will work for us.
>
> so, it could be something like:
>
> <cdecl: #( int foo (int bar , float baz )) module: #myModule>
>
> or:
> <ffi: #( cdecl int foo ... ) module: ... >
>

This is such a fascinating hack.  e.g.

#(int (*compar)(const void *, const void *))
    #(#int #(#* #compar) #(#const #void #*, #const #void #*))

#(int (struct { field : 8; fence : 8; gate: 16; } arg))
    #(#int #(#struct #'{' #field #':' 8 #';' #fence #':' 8 #';' #gate: 16
#';' #'}' #arg))

Can anyone prove that Igor's approach works for all C signatures?  What
about other languages?

I find this is like really dirty sex, repellent and irresistible at one and
the same time.


> The class for parsing function prototype can be found in SqS/NativeBoost
> in class NBFnSpecParser
> and tests are in:
> NBFnSpecParserTest in NativeBoost-Test package.
> (some of them are NB-specific) but its easy to rip out extra functionality
> :)
>
> Also, there is a wiki page explaining this format:
> http://code.google.com/p/nativeboost/wiki/NBFnSpecParser
>
> So, if we agree with plan, i could port this class and adopt it for
> compiler (and yes , by taking Lukas code as well)
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110324/4bdc08ed/attachment.htm