On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote:
> Le 1 mars 2012 21:30, Eliot Miranda <eliot.mira...@gmail.com> a écrit : > > > > > > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <esteba...@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-boun...@lists.gforge.inria.fr > >> > [pharo-project-boun...@lists.gforge.inria.fr] on behalf of > Schwab,Wilhelm K > >> > [bsch...@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-boun...@lists.gforge.inria.fr > >> > [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Esteban > Lorenzano > >> > [esteba...@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-boun...@lists.gforge.inria.fr > >> >> [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Esteban > Lorenzano > >> >> [esteba...@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-boun...@lists.gforge.inria.fr > >> >>> [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Esteban > Lorenzano > >> >>> [esteba...@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 <bsch...@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-boun...@lists.gforge.inria.fr > >> >>>>> [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor > Stasenko > >> >>>>> [siguc...@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 <bsch...@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
