[Pharo-project] Alien signature: first attempt

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Mar 1 17:40:54 EST 2012


Le 1 mars 2012 23:10, Eliot Miranda <eliot.miranda at gmail.com> a écrit :
>
>
> On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> Le 1 mars 2012 21:30, Eliot Miranda <eliot.miranda at gmail.com> a écrit :
>> >
>> >
>> > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm at gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> sorry for not sending before: work is hard :P
>> >> yes, that should work, and no, I don't know a better way to define it.
>> >
>> >
>> > No it won't work.  See my message.
>> >
>> >>
>> >> I think Eliot's idea is to form "libraries" of generic callbacks (for
>> >> mars, for instance, I have CocoaCallback, child of Callback, who
>> >> defines all
>> >> my needed signatures, looks a lot at first instance, but if you see in
>> >> detail, finally there are not so much variants)
>> >
>> >
>> > Yes, the idea is to have a library of signature methods that marshal
>> > specific C callback signatures to/from Smalltalk blocks.  The pragma
>> > specifies what ABI (application binary interface, or stack layout) the
>> > signature is for so that the scheme is cross-platform.  But I expect
>> > that
>> > these signature methods could be the output of an ABI compiler, so that
>> > one
>> > wouldn't have to write them by hand.  The pragma doesn't need to include
>> > a
>> > word-size since IA64 is a different ABI to IA32, and so the ABI subsumes
>> > word size.
>> >
>> > HTH
>> >
>>
>>
>> Let me understand...
>> If I have a signature (char x,double y, short z) IA-32, where is the
>> spalien pointing to?
>
>
> At the first parameter immediately below the return address.
>
>>
>> - the original call stack (with proper ABI alignment, that is offsets
>> 0,4,12, or 1-based indices 1,5,13)
>
>
> Right.
>
>>
>> - a serialized copy without alignment padding (offsets 0,1,9, or
>> 1-based indices 1,2,10)
>
>
> No.
>
>>
>> In the former case, that means that the indices must be computed
>> according to ABI (might be different in PPC for example).
>
>
> Right.  Hence the pragma containing the name of the ABI to allow the system
> to select the appropriate version.  Note that the implementation allows for
> passing a pointer to a struct containing marshalled register arguments for
> RISC platforms, although this isn't used yet since it's not needed on x86.
>
>>
>> And even if such code is generated with an ABI-aware interface
>> compiler, is it really platform independent?
>
>
> The scheme is platform-independent, allowing platform-specific versions of
> marshalling code to exist side-by-side.
>

OK, thanks that's clear.

>>
>> I'm quite sure the ABI have subtle variations, which are not even
>> platform but compiler specific...
>
>
> No.  That's the definition of an ABI.  The ABI specifies the calling
> convention for a particular platform, and compilers must conform to the ABI
> for all external and system calls.
>
>>
>> For example of such niceties in win32, did you ever try returning a
>> structure by value from a cdecl mingw-gcc compiled function to a cdecl
>> visual studio compiled caller, not even speaking of different internal
>> structure alignment padding (controlled with #pragma packed(4) or
>> other compiler options...)
>
>
> That's different.  Internal interfaces used by particular compilers are no
> covered by the ABI but then they aren't used for inter-component interfaces
> such as callbacks.  If you look, for example, at the Intel x86 compiler
> you'll see it'll use a register-based calling convention, multiple
> entry-points for functions (an internal and an external one), etc.  But
> these non-standard interfaces are only used internally, typically between
> functions within a single compilation unit.
>

OK, but in the structure by value case, I created functions exported
as public DLL entry points, and that did not make them
compiler-agnostic.
Unless I did something wrong, VisualStudio and gcc seem to have both a
different idea of cdecl (and stdcall too).

>>
>> This apple page helps a lot, for example it tells how gcc returns a
>> structure by value...
>>
>> https://developer.apple.com/library/mac/#documentation/developertools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html
>
>
> I know.  But the bibles in these cases are documents such as "SYSTEM V
> APPLICATION BINARY INTERFACE, Intel386? Architecture Processor
> Supplement, Fourth Edition".  You'll find a concise specification of the
> calling convention of the ABI, and structure layout etc, in chapter 3.
>
> cheers,
> Eliot

Yes, I'm pretty sure you know much more than me on the subject, I'm
very reluctant in dealing with such low level unless I'm forced to ;)
And a link to the bible can be found at bottom of apple page for the
other guys having to put some grease on their hands ;)

But from what I read, we should then have a MacOSX-IA-32 ABI and a
SystemV-i386 ABI which are mostly the same with a few exceptions noted
on top of apple's page, and structure returned by value are one such
exception.
My 2¢ advice would be to avoid such exception (for example write a
wrapper that pass a pointer to the struct instead).
Otherwise, one should be prepared to read technical specs and
understand how to write his own marshaller.

Nicolas

>>
>>
>>
>> Nicolas
>>
>> >>
>> >>
>> >> best,
>> >> Esteban
>> >>
>> >> El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribió:
>> >>
>> >> > Esteban,
>> >> >
>> >> > Will this work?  Even if so, is there a better way to define it?
>> >> >
>> >> > longVoidStarLongRetInt: callbackContext sp: spAlien
>> >> >       <signature: 'int (*) (long, void *, long)' abi: 'IA32'>
>> >> >       ^callbackContext wordResult:
>> >> >               (block
>> >> >                       value: (Alien newC:4)
>> >> >                       value: (Alien forPointer: (spAlien
>> >> > unsignedLongAt:
>> >> > 5))
>> >> >                       value: (Alien newC:4)
>> >> >               )
>> >> >
>> >> > Bill
>> >> >
>> >> > ________________________________________
>> >> > From: pharo-project-bounces at lists.gforge.inria.fr
>> >> > [pharo-project-bounces at lists.gforge.inria.fr] on behalf of
>> >> > Schwab,Wilhelm K
>> >> > [bschwab at anest.ufl.edu]
>> >> > Sent: Thursday, March 01, 2012 12:15 AM
>> >> > To: Pharo-project at lists.gforge.inria.fr
>> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >> >
>> >> > thanks!!!!!
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ________________________________________
>> >> > From: pharo-project-bounces at lists.gforge.inria.fr
>> >> > [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Esteban
>> >> > Lorenzano
>> >> > [estebanlm at gmail.com]
>> >> > Sent: Wednesday, February 29, 2012 10:18 PM
>> >> > To: Pharo-project at lists.gforge.inria.fr
>> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >> >
>> >> > you need to define a signature... not at home now, but wait 'til
>> >> > tomorrow and I'll send an example
>> >> >
>> >> > best,
>> >> > Esteban
>> >> >
>> >> > El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribió:
>> >> >
>> >> >> What does "cannot find callback signature" mean from
>> >> >> #signature:block:?
>> >> >>  I'm stuck.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ________________________________________
>> >> >> From: pharo-project-bounces at lists.gforge.inria.fr
>> >> >> [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Esteban
>> >> >> Lorenzano
>> >> >> [estebanlm at gmail.com]
>> >> >> Sent: Wednesday, February 29, 2012 6:54 PM
>> >> >> To: Pharo-project at lists.gforge.inria.fr
>> >> >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >> >>
>> >> >> yeah... sorry about that
>> >> >> is a bug on FFI... I managed to worked around it for HPDF, for a
>> >> >> customer's project... but of course is not a good and definitive
>> >> >> solution.
>> >> >>
>> >> >> best,
>> >> >> Esteban
>> >> >>
>> >> >> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribió:
>> >> >>
>> >> >>> This is gonna take a while...   I had structs flying around as
>> >> >>> void*
>> >> >>> and was moderately happy.  Nonetheless, your suggestion worked,
>> >> >>> provided I
>> >> >>> add a lot getHandle asInteger and change the void* to long :(
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> ________________________________________
>> >> >>> From: pharo-project-bounces at lists.gforge.inria.fr
>> >> >>> [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Esteban
>> >> >>> Lorenzano
>> >> >>> [estebanlm at gmail.com]
>> >> >>> Sent: Wednesday, February 29, 2012 6:23 PM
>> >> >>> To: Pharo-project at lists.gforge.inria.fr
>> >> >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >> >>>
>> >> >>> I also found some problems using void* in linux... maybe you want
>> >> >>> to
>> >> >>> use long (which has same size)... I "fixed" my problems that way.
>> >> >>>
>> >> >>> yes... maybe we need to look at FFI to see why void* has problems
>> >> >>> some
>> >> >>> times, but well, that can help you atm (sorry for not having a
>> >> >>> better
>> >> >>> answer)
>> >> >>>
>> >> >>> Esteban
>> >> >>>
>> >> >>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribió:
>> >> >>>
>> >> >>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab at anest.ufl.edu>
>> >> >>>> wrote:
>> >> >>>>> Another glitch: is there any problem passing things as void*?
>> >> >>>>>  I'm
>> >> >>>>> getting failure to coerce errors that did not arise before.
>> >> >>>>>
>> >> >>>> No idea. As you may suspect, i stopped using FFI/Alien once i got
>> >> >>>> NativeBoost toy to play with.
>> >> >>>>
>> >> >>>> Please file the issue, describing the problem. so we can look over
>> >> >>>> it
>> >> >>>> and fix it.
>> >> >>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> ________________________________________
>> >> >>>>> From: pharo-project-bounces at lists.gforge.inria.fr
>> >> >>>>> [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Igor
>> >> >>>>> Stasenko
>> >> >>>>> [siguctua at gmail.com]
>> >> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM
>> >> >>>>> To: Pharo-project at lists.gforge.inria.fr
>> >> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >> >>>>>
>> >> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab at anest.ufl.edu>
>> >> >>>>> wrote:
>> >> >>>>>> Does 1.3 by default not create field accessors?  Why is that?  I
>> >> >>>>>> thought
>> >> >>>>>> nothing was happening.
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>> Good question, i'd like to know the answer too.
>> >> >>>>> It is related to MC final 'installation' phase,
>> >> >>>>> where it initializing all classes.
>> >> >>>>>
>> >> >>>>> In NativeBoost i was also using
>> >> >>>>>
>> >> >>>>> noteCompilationOf: aSelector meta: isMeta
>> >> >>>>>     "A hook allowing some classes to react to recompilation of
>> >> >>>>> certain selectors"
>> >> >>>>>
>> >> >>>>> but there was a big question, at which point this hook is
>> >> >>>>> triggered,
>> >> >>>>> and looks like some changes in MC stop triggering it/triggering
>> >> >>>>> at
>> >> >>>>> wrong time (not all methods get into a class/ class not
>> >> >>>>> initialized
>> >> >>>>> etc),
>> >> >>>>> which makes it not very useful.
>> >> >>>>>
>> >> >>>>> So i ended up creating a DNU handler on instance side, then on
>> >> >>>>> DNU i
>> >> >>>>> check if i have field accessors and if not,
>> >> >>>>> compile them on the fly.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> Bill
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> Best regards,
>> >> >>>>> Igor Stasenko.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> Best regards,
>> >> >>>> Igor Stasenko.
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>>
>
>
>
> --
> best,
> Eliot
>




More information about the Pharo-dev mailing list