[Pharo-project] Alien signature: first attempt

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 1 17:10:25 EST 2012


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.


> 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.


> 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

>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120301/6bab66a9/attachment-0001.html>


More information about the Pharo-dev mailing list