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

[John McIntosh]

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;

}

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
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151020/3a1be3ba/attachment.htm