[Vm-dev] 64-bit plugin support

Thu Apr 2 22:41:02 UTC 2015

On Thu, Apr 2, 2015 at 3:29 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
>
> 2015-04-02 23:49 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Thanks Nicolas!
>>
>>    two very minor points.  a) you can use #sqLong instead of #'unsigned
>> long' and b) you don't need to say #'long', you can just say #long. hence
>>     <var: 'foo' type: #long>
>>     <var: 'bar' type: #sqLong>
>>
>>
> Hi Eliot,
> but sqLong is long long (64 bits) on a 32bit VM isn't it?
> I want an __int32 on a 32bits VM and an __int64 on a 64 bits VM.
>

Doh!  That's right.

> On current architectures, long or unsigned long fits.
> I also use unsigned long rather than signed to match return type of
> positiveMachineIntegerValueOf:
>
> Note that you can also take the MacMenuBarPlugin fix from previous post :)
>

Will do, thanks!

>
> cheers
>
>
>
>> On Thu, Apr 2, 2015 at 1:28 PM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>>
>>> Here is a new patch attached.
>>>
>>> 2015-04-02 16:26 GMT+02:00 Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com>:
>>>
>>>>
>>>>
>>>> 2015-04-02 3:56 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
>>>>
>>>>>
>>>>> On Wed, Apr 01, 2015 at 10:16:37PM +0200, Nicolas Cellier wrote:
>>>>> >
>>>>> > Hello,
>>>>> > I noticed a few #positive32BitValueOf: usage in plugins for the
>>>>> purpose of
>>>>> > retrieving a pointer stored in a #sqInt or #usqInt.
>>>>>
>>>>> That would definitely be wrong. Any plugin that stores machine
>>>>> pointers in
>>>>> sqInt or usqInt is broken.
>>>>>
>>>>> There are number of plugins that are still not updated for 64-bit VMs.
>>>>> I've
>>>>> tried to track some of the status of this on bugs.squeak.org although
>>>>> the
>>>>> information is not complete.
>>>>>
>>>>> Of the top of my head, I think that the SSL plugin, Camera plugin,
>>>>> anything
>>>>> dependent on SurfacePlugin, and probably a few others are broken.
>>>>> FFIPlugin
>>>>> was notably broken (with the fixes are on Mantis but not integrated),
>>>>> though
>>>>> that my no longer be relevant with newer FFI plugins.
>>>>>
>>>>> >
>>>>> > Yes, a #sqInt is large enough to hold a pointer, but shouldn't it be
>>>>> filled
>>>>> > with positiveMachineIntegerValueOf:?
>>>>> > At least this is necessary for spur64.
>>>>>
>>>>> A sqInt is *not* large enough to hold a pointer, specifically in the
>>>>> most
>>>>> common case of a 32-bit object memory running on a 64-bit interpreter
>>>>> VM.
>>>>>
>>>>>
>>>>
>>>> >
>>>>> > Here are 3 patches attached.
>>>>> >
>>>>> > Nicolas
>>>>>
>>>>> Thanks! I know your patches are focused on Spur but I'll try running
>>>>> them also on
>>>>> the interpreter VM as soon as I am able. Note that
>>>>> positiveMachineIntegerValueOf:
>>>>> is a Spur idiom, although I would not expect that it would necessary
>>>>> to rely on that,
>>>>> since usually just declaring the variables correctly is sufficient. So
>>>>> for example in
>>>>>
>>>>> QuicktimePlugin>>primitiveSetGWorldPtrOntoSurface:width:height:rowBytes:depth:movie:
>>>>> there is a variable #buffer that looks like it needs to be a (char *),
>>>>> but is undeclared
>>>>> and takes the default #sqInt. Casting it to (char *) will always fail
>>>>> in the case of
>>>>> a 32-bit sqInt on a 64-bit host platform, regardless of which idiom
>>>>> you use in the
>>>>> cCoerce cast. It is better to declare both #buffer and #bitMapPtr
>>>>> explicitly, and
>>>>> get rid of the cast. That usually requires also fixing up the
>>>>> declarations in the
>>>>> support code and header files in ./Cross, but that's probably the only
>>>>> way to get
>>>>> it right.
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>> Let me reformulate.
>>>>
>>>> My patch is for the case when we stored an external pointer (a handle
>>>> or something) into an Integer at image side (possibly a LargeInteger).
>>>>
>>>> When the image is willing to pass the handle back to another primitive
>>>> of the plugin, the conversion from smalltalk Small/LargeInteger -> pointer
>>>> has to occur one way or another.
>>>>
>>>> As I see it, something as positiveMachineIntegerValueOf: that would use
>>>> either 32 or 64 bits variant depending on wordSize is the way to go.
>>>>
>>>> What you say, is that the variable that holds the pointer should not be
>>>> declared #sqInt, because even if it works with Spur64, it's not large
>>>> enough in classical Interpreter.
>>>>
>>>> The classical Interpreter version of positiveMachineIntegerValueOf:
>>>> could answer an unsigned long for example (asserting that
>>>> (sizeof(long)>=wordSize)), so we can continue using that message for the
>>>> compatibility layer (having single plugin variant for several VM brands).
>>>>
>>>> But you are right, the plugin itself should not use a #sqInt
>>>> declaration for holding the handle/pointer - even if it works with Spur64,
>>>> I'll try to make another pass with that in mind.
>>>>
>>>> Nicolas
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150402/e78ad035/attachment-0001.htm