[Vm-dev] Alien on Spur and "el capitan"?

Tue Oct 20 21:53:15 UTC 2015

Hi John, Hi Esteban,

On Tue, Oct 20, 2015 at 2:48 PM, John McIntosh <
johnmci at smalltalkconsulting.com> wrote:

>
> Sure but I see the follow use cases, which are best confusing, and just
> curious if they work as you think they should?
> Does clang optimize out the  (value >= 0) if value is a unsigned type?
>
> /* begin maybeInlinePositive32BitIntegerFor: */
>
> assert(!((hasSixtyFourBitImmediates())));
>
> if ((stackPtr >= 0)
>
> && ((stackPtr ^ (stackPtr << 1)) >= 0)) {
>
> ((stackPtr << 1) | 1);
>
> goto l2;
>
> }
> where stackPtr is
> sendInvokeCallbackStackRegistersJmpbuf(sqInt thunkPtr, sqInt stackPtr,
> sqInt regsPtr, sqInt jmpBufPtr)
>
>  or  where integerValue is saint  btw  so casting to usqInt then back to
> saint is 'magic handwaving?'
>
> integerValue = ((usqInt)usecs);
>
> /* begin maybeInlinePositive32BitIntegerFor: */
>
> assert(!((hasSixtyFourBitImmediates())));
>
> if ((integerValue >= 0)
>
> && ((integerValue ^ (integerValue << 1)) >= 0)) {
>
> v1 = ((integerValue << 1) | 1);
>
> goto l1;
>
> }
>
>
> or this where value is declared as 'unsigned long' versus a squeak data
> type
>
>
> value = ((usqInt)((vmCallbackContext->thunkp)));
>
> /* begin positive32BitIntegerFor: */
>
> /* begin maybeInlinePositive32BitIntegerFor: */
>
> assert(!((hasSixtyFourBitImmediates())));
>
> if ((value >= 0)
>
> && ((value ^ (value << 1)) >= 0)) {
>
> ((value << 1) | 1);
>
> goto l2;
>
> }
>

So first of all, this code is out of date.  This method should read the
following; notice the use of positiveMachineIntegerValueOf:, not
positive32BitIntegerFor:

sendInvokeCallback: thunkPtr Stack: stackPtr Registers: regsPtr Jmpbuf:
jmpBufPtr
"Send the 4 argument callback message invokeCallback:stack:registers:jmpbuf:
to Alien class with the supplied args.  The arguments are raw C addresses
and are converted to integer objects on the way."
<export: true>
| classTag |
classTag := self fetchClassTagOfNonImm: (self splObj: ClassAlien).
messageSelector := self splObj: SelectorInvokeCallback.
argumentCount := 4.
(self lookupInMethodCacheSel: messageSelector classTag: classTag) ifFalse:
[(self lookupOrdinaryNoMNUEtcInClass: (objectMemory classForClassTag:
classTag)) ~= 0 ifTrue:
[^false]].
((self argumentCountOf: newMethod) = 4
and: [primitiveFunctionPointer = 0]) ifFalse:
[^false].
self push: (self splObj: ClassAlien). "receiver"
self push: (self positiveMachineIntegerFor: thunkPtr).
self push: (self positiveMachineIntegerFor: stackPtr).
self push: (self positiveMachineIntegerFor: regsPtr).
self push: (self positiveMachineIntegerFor: jmpBufPtr).
self ifAppropriateCompileToNativeCode: newMethod selector: messageSelector.
self justActivateNewMethod.
(self isMachineCodeFrame: framePointer) ifFalse:
[self maybeFlagMethodAsInterpreted: newMethod].
self externalWriteBackHeadFramePointers.
self handleStackOverflow.
self enterSmalltalkExecutiveFromCallback.
"not reached"
^true

Second of all, this whole method is obsolete.  It's there for old-style
Alien callbacks.  You should be using new-style Alien callbacks that use
invokeCallbackContext: and sendInvokeCallbackContext:.

sendInvokeCallbackContext: vmCallbackContext
"Send the calllback message to Alien class with the supplied arg(s).  Use
either the
1 arg invokeCallbackContext: or the 4 arg
invokeCallback:stack:registers:jmpbuf:
message, depending on what selector is installed in the specialObjectsArray.
Note that if invoking the legacy invokeCallback:stack:registers:jmpbuf: we
pass the
vmCallbackContext as the jmpbuf argument (see
reestablishContextPriorToCallback:).
The arguments are raw C addresses and are converted to integer objects on
the way."
<export: true>
<var: #vmCallbackContext type: #'VMCallbackContext *'>
| classTag |
classTag := self fetchClassTagOfNonImm: (self splObj: ClassAlien).
messageSelector := self splObj: SelectorInvokeCallback.
(self lookupInMethodCacheSel: messageSelector classTag: classTag) ifFalse:
[(self lookupOrdinaryNoMNUEtcInClass: (objectMemory classForClassTag:
classTag)) ~= 0 ifTrue:
[^false]].
primitiveFunctionPointer ~= 0 ifTrue:
[^false].
self saveCStackStateForCallbackContext: vmCallbackContext.
self push: (self splObj: ClassAlien). "receiver"
(self argumentCountOf: newMethod) = 4 ifTrue:
[self push: (self positiveMachineIntegerFor: vmCallbackContext thunkp
asUnsignedInteger).
self push: (self positiveMachineIntegerFor: vmCallbackContext stackp
asUnsignedInteger).
self push: (self positiveMachineIntegerFor: vmCallbackContext intregargsp
asUnsignedInteger)].
self push: (self positiveMachineIntegerFor: vmCallbackContext
asUnsignedInteger).
self ifAppropriateCompileToNativeCode: newMethod selector: messageSelector.
self justActivateNewMethod.
(self isMachineCodeFrame: framePointer) ifFalse:
[self maybeFlagMethodAsInterpreted: newMethod].
self externalWriteBackHeadFramePointers.
self handleStackOverflow.
self enterSmalltalkExecutiveFromCallback.
"not reached"
^true

> On Tue, Oct 20, 2015 at 2:34 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>> Hi John,
>>
>> On Tue, Oct 20, 2015 at 1:59 PM, John McIntosh <
>> johnmci at smalltalkconsulting.com> wrote:
>>
>>>
>>> Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH
>>> unsigned and signed integers? That to me rings alarm bells, so do you
>>> need maybeInlinePositive32BitIntegerForSignedInteger
>>> or maybeInlinePositive32BitIntegerForUnSignedInteger  or always cast the
>>> incoming value to an unsigned integer, or is it signed? If so are you sure
>>> you understand the math involved and the possible input values?
>>>
>>
>> No, we don't need this.  Looking at the code, it is OK for
>> positive32BitIntegerFor: to truncate to 32-bits.  But if one wants to pass
>> in a 32-bit value form a long one should write
>>
>>     ^self positive32BitIntegerFor: (value bitAnd: 16rFFFFFFFF)
>>
>> If one wants a value which is as big as a pointer one should use
>>
>>  ^self positiveMachineIntegerFor: (value bitAnd: 16rFFFFFFFF)
>>
>> Only use the 32Bit conversion routines when you want a 32-bit result.
>> There are now 32-bit, 64-bit and machine versions of the conversion
>> routines.  The machine versions answer 32 or 64 bit results as appropriate.
>>
>>
>>>
>>>
>>>
>>> On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm at gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> Does anyone tested Alien on Spur and "El capitan"? specifically
>>>> callbacks?
>>>> For me, a completely broken :(
>>>>
>>>> 1) this structure (in maybeInlinePositive32BitIntegerFor: and others):
>>>>
>>>> (integerValue >= 0
>>>> and: [objectMemory isIntegerValue: integerValue]) ifTrue:
>>>> [^objectMemory integerObjectOf: integerValue].
>>>>
>>>> Does not works if “integer value” is an unsigned long, because compiler
>>>> assumes it will always be true, then remove the if, then answers a wrong
>>>> value.
>>>>
>>>> 2) assertCStackWellAligned always fail. No idea why because if does
>>>> not says anything, just jmp back to the regular flow.
>>>>
>>>> 3) finally, ceCaptureCStackPointers also fails… this can be because
>>>> (2) or because other reasons (it also jmps back so no clue) (method
>>>> generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped
>>>> to work).
>>>>
>>>> I guess solution of (1) is easy: argument number just has to be a
>>>> sqLong instead an unsigned long.
>>>>
>>>> But for 2 and 3 I have no idea where to start.
>>>>
>>>> Does anyone has an idea?
>>>>
>>>> Esteban
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> ===========================================================================
>>> John M. McIntosh. Corporate Smalltalk Consulting Ltd
>>> https://www.linkedin.com/in/smalltalk
>>>
>>> ===========================================================================
>>>
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
>
> --
> ===========================================================================
> John M. McIntosh. Corporate Smalltalk Consulting Ltd
> https://www.linkedin.com/in/smalltalk
> ===========================================================================
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151020/5448082c/attachment.htm