Le 1 mars 2012 23:10, Eliot Miranda <[email protected]> a écrit : > > > On Thu, Mar 1, 2012 at 1:15 PM, Nicolas Cellier > <[email protected]> wrote: >> >> Le 1 mars 2012 21:30, Eliot Miranda <[email protected]> a écrit : >> > >> > >> > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <[email protected]> >> > 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: [email protected] >> >> > [[email protected]] on behalf of >> >> > Schwab,Wilhelm K >> >> > [[email protected]] >> >> > Sent: Thursday, March 01, 2012 12:15 AM >> >> > To: [email protected] >> >> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> > >> >> > thanks!!!!! >> >> > >> >> > >> >> > >> >> > >> >> > ________________________________________ >> >> > From: [email protected] >> >> > [[email protected]] on behalf of Esteban >> >> > Lorenzano >> >> > [[email protected]] >> >> > Sent: Wednesday, February 29, 2012 10:18 PM >> >> > To: [email protected] >> >> > 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: [email protected] >> >> >> [[email protected]] on behalf of Esteban >> >> >> Lorenzano >> >> >> [[email protected]] >> >> >> Sent: Wednesday, February 29, 2012 6:54 PM >> >> >> To: [email protected] >> >> >> 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: [email protected] >> >> >>> [[email protected]] on behalf of Esteban >> >> >>> Lorenzano >> >> >>> [[email protected]] >> >> >>> Sent: Wednesday, February 29, 2012 6:23 PM >> >> >>> To: [email protected] >> >> >>> 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 <[email protected]> >> >> >>>> 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: [email protected] >> >> >>>>> [[email protected]] on behalf of Igor >> >> >>>>> Stasenko >> >> >>>>> [[email protected]] >> >> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM >> >> >>>>> To: [email protected] >> >> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> >>>>> >> >> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <[email protected]> >> >> >>>>> 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 >
