[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