[Vm-dev] Re: FFI syntax

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Thu Mar 24 19:30:03 UTC 2011


On 24.03.2011 20:10, Eliot Miranda wrote:
>   
>
>
>
>
> On Thu, Mar 24, 2011 at 12:02 PM, Igor Stasenko <siguctua at gmail.com 
> <mailto:siguctua at gmail.com>> wrote:
>
>
>     On 24 March 2011 19:43, Eliot Miranda <eliot.miranda at gmail.com
>     <mailto:eliot.miranda at gmail.com>> wrote:
>     >
>     >
>     >
>     > 2011/3/24 Levente Uzonyi <leves at elte.hu <mailto: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.
Thank you for putting words to my feeling at the time I suggested it :)
Don't know if it works for every signature though, only the examples he 
gave of the old format :/

Cheers,
Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110324/6cd6fa06/attachment.htm


More information about the Vm-dev mailing list