[Pharo-project] Alien signature: first attempt

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Mar 1 16:15:01 EST 2012


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?
- the original call stack (with proper ABI alignment, that is offsets
0,4,12, or 1-based indices 1,5,13)
- a serialized copy without alignment padding (offsets 0,1,9, or
1-based indices 1,2,10)

In the former case, that means that the indices must be computed
according to ABI (might be different in PPC for example).

And even if such code is generated with an ABI-aware interface
compiler, is it really platform independent?
I'm quite sure the ABI have subtle variations, which are not even
platform but compiler specific...
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...)

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

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
>




More information about the Pharo-dev mailing list