Hi David, John, All,
I'm working on integrating callbacks into the FFI and have the old version of callbacks working. In integrating with Cog I've realised some cleanliness can come from a slightly different approach, the details of which are irrelevant to my question, which is, when we're running a 32-bit image above a 32-bit VM compiled in 64-bit mode, is there any way from the image we can ask the VM if it is 64-bit or 32-bit? Am I to understand correctly that you, John, have arranged that when we're compiling the iOS VM on a 64-bit Mac OS X, sizeof(long) = 8, and everything still works? If not, the question is moot. If so, how from the image can I ask whether the VM is 64-bit, e.g. by asking what sizeof(long) or sizeof(void *) is?
If there isn't a way, I propose we add vmParameterAt: 70 to answer the VM's underlying word size. Tis is different to vmParameterAt: 40, which is the image's underlying word size.
I need the answer to this so that when a callback tries to answer e.g. an integer result it can tell whether it should use some Alien signedLongAt: N or Alien signedLongLongAt: N to answer the result, and what machine code (x86 vs x86-64) to use for the callback thunk.
best Eliot
Ok, well I've not lately compiled a VM that runs as 64bit binary against a 32bit image. (july of this year). But yes if you asked for sizeof(long) you would get 4, so yes sizeof(long) (4) versus sizeof(void*) (8) would be different. And yes 5.7 minus most plugins did work when run as a 64bit executable.
I've never compiled up a 64bit binary, 32bit image for Cog.
But isn't there also the Squeak image word size to consider since it could be a 32bit vm running a 64bit image. Mind I didn't compile one of those up..
On 2010-10-12, at 7:21 PM, Eliot Miranda wrote:
Hi David, John, All,
I'm working on integrating callbacks into the FFI and have the old version of callbacks working. In integrating with Cog I've realised some cleanliness can come from a slightly different approach, the details of which are irrelevant to my question, which is, when we're running a 32-bit image above a 32-bit VM compiled in 64-bit mode, is there any way from the image we can ask the VM if it is 64-bit or 32-bit? Am I to understand correctly that you, John, have arranged that when we're compiling the iOS VM on a 64-bit Mac OS X, sizeof(long) = 8, and everything still works? If not, the question is moot. If so, how from the image can I ask whether the VM is 64-bit, e.g. by asking what sizeof(long) or sizeof(void *) is?
If there isn't a way, I propose we add vmParameterAt: 70 to answer the VM's underlying word size. Tis is different to vmParameterAt: 40, which is the image's underlying word size.
I need the answer to this so that when a callback tries to answer e.g. an integer result it can tell whether it should use some Alien signedLongAt: N or Alien signedLongLongAt: N to answer the result, and what machine code (x86 vs x86-64) to use for the callback thunk.
best Eliot
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Tue, Oct 12, 2010 at 07:39:40PM -0700, John M McIntosh wrote:
Ok, well I've not lately compiled a VM that runs as 64bit binary against a 32bit image. (july of this year). But yes if you asked for sizeof(long) you would get 4, so yes sizeof(long) (4) versus sizeof(void*) (8) would be different. And yes 5.7 minus most plugins did work when run as a 64bit executable.
I've never compiled up a 64bit binary, 32bit image for Cog.
But isn't there also the Squeak image word size to consider since it could be a 32bit vm running a 64bit image. Mind I didn't compile one of those up..
Actually, the image word size should be a non-issue here. A 64-bit image works the same regardless of whether the interpreter was compiled for a 32 or 64-bit host. It just runs a lot slower on a 32-bit interpreter.
I have gotten the FFI running successfully on a 64-bit image and 64-bit interpreter, so all combinations of 32/64 bit images and hosts can be made to work with FFI.
Dave
On Tue, Oct 12, 2010 at 07:21:25PM -0700, Eliot Miranda wrote:
Hi David, John, All,
I'm working on integrating callbacks into the FFI and have the old
version of callbacks working. In integrating with Cog I've realised some cleanliness can come from a slightly different approach, the details of which are irrelevant to my question, which is, when we're running a 32-bit image above a 32-bit VM compiled in 64-bit mode, is there any way from the image we can ask the VM if it is 64-bit or 32-bit? Am I to understand correctly that you, John, have arranged that when we're compiling the iOS VM on a 64-bit Mac OS X, sizeof(long) = 8, and everything still works? If not, the question is moot. If so, how from the image can I ask whether the VM is 64-bit, e.g. by asking what sizeof(long) or sizeof(void *) is?
If there isn't a way, I propose we add vmParameterAt: 70 to answer the VM's underlying word size. Tis is different to vmParameterAt: 40, which is the image's underlying word size.
I need the answer to this so that when a callback tries to answer e.g. an integer result it can tell whether it should use some Alien signedLongAt: N or Alien signedLongLongAt: N to answer the result, and what machine code (x86 vs x86-64) to use for the callback thunk.
You definitely want to make a distinction between sizeof(long) and sizeof(void *), because long can be defined differently on different 64-bit implementations. In particular, some 64-bit platforms have used 32-bit longs, so you can't rely on a single parameter for this.
In OSProcessPlugin, there are #primitiveSizeOfPointer and #primitiveSizeOfInt primitives. Implementation is trivial, so these kinds of primitives could be added to the interpreter or into whatever plugin you have associated with the FFI. To me, a primitive seems more explicit in intent than a vmParameter, and since you are likely to end up needing to know the size of pointers, ints, longs, floats, etc, I would be inclined to do the inquiries with explicit primitive calls rather than a set of VM parameters.
There is a large batch of changes that I did for the classic FFI mechanism to make it work on 64-bit platforms (almost 3 years ago now - yikes!). Details here: http://lists.squeakfoundation.org/pipermail/vm-dev/2008-May/001945.html
And (probably outdated) patches: http://bugs.squeak.org/view.php?id=7237
I had intended to get this folded into the VM a long time ago, but it is a fairly large change so I did not push it too hard. That said, if you are doing new work on this, it might be worthwhile to get the old FFI updated if only as a point of reference. Frankly I think it's too much of a change to do in the December time frame (next release of VMs) but perhaps as a new years resolution for next January?
Dave
vm-dev@lists.squeakfoundation.org