Smalltalk › Squeak › Squeak VM

64-bit compilation beneath a 32-bit image...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Eliot Miranda-2

64-bit compilation beneath a 32-bit image...

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

johnmci

Re: 64-bit compilation beneath a 32-bit image...

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 <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

smime.p7s (5K) Download Attachment

David T. Lewis

Re: 64-bit compilation beneath a 32-bit image...

In reply to this post by Eliot Miranda-2

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

David T. Lewis

Re: 64-bit compilation beneath a 32-bit image...

In reply to this post by johnmci

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