On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

Le 1 mars 2012 21:30, Eliot Miranda <eliot.miranda@gmail.com> a �crit :

>
>
> On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm@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@lists.gforge.inria.fr
>> > [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K
>> > [bschwab@anest.ufl.edu]
>> > Sent: Thursday, March 01, 2012 12:15 AM
>> > To: Pharo-project@lists.gforge.inria.fr
>> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >
>> > thanks!!!!!
>> >
>> >
>> >
>> >
>> > ________________________________________
>> > From: pharo-project-bounces@lists.gforge.inria.fr
>> > [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano
>> > [estebanlm@gmail.com]
>> > Sent: Wednesday, February 29, 2012 10:18 PM
>> > To: Pharo-project@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@lists.gforge.inria.fr
>> >> [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano
>> >> [estebanlm@gmail.com]
>> >> Sent: Wednesday, February 29, 2012 6:54 PM
>> >> To: Pharo-project@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@lists.gforge.inria.fr
>> >>> [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano
>> >>> [estebanlm@gmail.com]
>> >>> Sent: Wednesday, February 29, 2012 6:23 PM
>> >>> To: Pharo-project@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@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@lists.gforge.inria.fr
>> >>>>> [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko
>> >>>>> [siguctua@gmail.com]
>> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM
>> >>>>> To: Pharo-project@lists.gforge.inria.fr
>> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>> >>>>>
>> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab@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