Re: [Pharo-project] Status of Alien FFI
Eliot, Johan, Fernando, et. al.: On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote:
Hi Ken,
On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <ken@miriamtech.com> wrote: Perhaps there would need to be new primitives for the basic size of each relevant C type? I'm anxious to hear what Eliot might have to say about this since he's got about 2000x more experience with this than I do.
are you using the 64-bit VM? If you're using a 32-bit VM on a 64- bit platform then yu're using 32-bits and you'll be linking against 32-bit libraries and hence nothing will have changed.
At present I'm on a 32-bit VM, but I'm trying to build a package that'll work both on Squeak/Pharo and on GemStone/S 64.
Alien has support for 64-bit values. Of course it uses the Windows choice, short = 2, int unused as a name, long = 4, longLong = 8. e.g. anAlien unsignedByteAt: oneRelativeIndex anAlien unsignedShortAt: oneRelativeIndex anAlien unsignedLongAt: oneRelativeIndex anAlien unsignedLongLongAt: oneRelativeIndex are the basic primitives for fetching unsigned integers.
But this needs to be wrapped with something that selects the right sizes based on the current platform and that's yet to be addressed.
OK, I took a first stab at this. In Alien-Core-KenTreis.57, I added the a class variable that holds a dictionary of platform sizes, along with accessors on Alien class for sizeof(type)[1]. I am imagining that this dictionary could be populated with a primitive, but for now it has to be set by hand. Probably high time I learned how to build Squeak primitives, but deadlines are calling... I also added Alien>>signedIntAt:/put: and unsignedIntAt:/put:. Right now these assume you're on an IA32 architecture (heck, that's the name of the plugin). But at least they hide that detail from the CairoGraphics package, which can simply use `Alien sizeofInt` in offset calculations and `Alien sizeofPointer` when data structures don't align nicely on 8-byte boundaries. Other changes in this version: * Class-side convenience callout helpers on AlienLibrary (e.g. int:with:, void:withArguments:, etc). These defer their actual behavior to primitives on the singleton instance, but provide for (IMHO) cleaner invocation from other objects. * Flush the list of loaded libraries at image startup, like the original Alien package did, instead of doing it at image shutdown as later versions do. This lets you save the image without dropping all of your libraries and invalidating external references. * A couple of accessors on AlienWeakTable that let you find a registered object by tag (analogous to Dictionary>>keyAtValue:), remove by tag, and return a strong reference to everything that the table currently holds weakly. The Cairo package uses these when handles are explicitly released and when flushing handles at image startup. I'm lobbying for inclusion of all of these in the trunk, but I'll be glad to defer to the better judgement of the package maintainers if my code is determined to be wrong/misguided. At this point this all works for me, and works well enough that I can load CairoGraphics and my "alien lite" in GemStone, and the various pointers, data offsets, etc. are right for Linux/x86_64. [1] I know there were some accessors for a few types already, but it seemed odd to have implementors for both signedLongSize and unsignedLongSize since the size doesn't depend on the sign-edness. I liked the C-like use of sizeofLong, sizeofPointer, etc but am willing to defer to somebody else's judgement on these method names. -- Ken Treis Miriam Technologies, Inc.
I'll note the most modern squeak VM's return wordSize, this might be helpful somewhere. wordSize "Answer the size (in bytes) of an object pointer." "Smalltalk wordSize" ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4] On 2009-09-22, at 4:16 PM, Ken Treis wrote:
Eliot, Johan, Fernando, et. al.:
On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote:
Hi Ken,
On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <ken@miriamtech.com> wrote: Perhaps there would need to be new primitives for the basic size of each relevant C type? I'm anxious to hear what Eliot might have to say about this since he's got about 2000x more experience with this than I do.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On Tue, Sep 22, 2009 at 04:47:56PM -0700, John M McIntosh wrote:
On 2009-09-22, at 4:16 PM, Ken Treis wrote:
Eliot, Johan, Fernando, et. al.:
On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote:
Hi Ken,
On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <ken@miriamtech.com> wrote: Perhaps there would need to be new primitives for the basic size of each relevant C type? I'm anxious to hear what Eliot might have to say about this since he's got about 2000x more experience with this than I do.
I'll note the most modern squeak VM's return wordSize, this might be helpful somewhere.
wordSize "Answer the size (in bytes) of an object pointer." "Smalltalk wordSize"
^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4]
Actually, this is just the size of an object "pointer" in the object memory (i.e. BytesPerWord in ObjectMemory), which is independent of the size of a C pointer. So you would need new primitives to get at the underlying machine data types. The implementations are trivial if you are writing a plugin anyway, for example see #primitiveSizeOfPointer and #primitiveSizeOfInt in OSProcessPlugin. The "pointer" terminology referring to words the object memory is needlessly confusing, I guess we should clean that up one of these days. Dave
Please David :) cleaning cleaning improving....letting people grow their understanding and create new things....
The "pointer" terminology referring to words the object memory is needlessly confusing, I guess we should clean that up one of these days.
Dave
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
David T. Lewis -
John M McIntosh -
Ken Treis -
Stéphane Ducasse