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

[Nicolas Cellier]

Doesn't the problem come from not respecting signedness when inlining?
Or from having incompatible type hint in caller/callee when inlining?

If signedness differs, there the callee parameter should be inlined with a
different variable and an explicit cast.
Most time, we should arrange to not have a signedness difference.
That's what I'm trying to achieve in my experimental branch.
But it's soliloquy..

2015-10-20 23:59 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
>
>
> On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>>
>> On 20 Oct 2015, at 23:50, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>>
>>
>> On 20 Oct 2015, at 23:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Esteban,
>>
>> On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano <estebanlm at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 20 Oct 2015, at 22:59, 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?
>>>
>>>
>>> I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot
>>> who is doing it :)
>>> But yes, I thought that first, then I followed the logic and figured out
>>> the intent was kept just changing the input type… but I might be wrong…
>>> Eliot should know better :)
>>>
>>
>> what's the context?
>>
>>
>> I spotted the problem when calling
>>
>> sendInvokeCallbackContext:
>>
>> in concrete, when doing this:
>>
>> self push: (self positiveMachineIntegerFor: vmCallbackContext
>> asUnsignedInteger).
>>
>> positiveMachineIntegerFor: always inlines the callback context (answering
>> then a random position in memory).
>>
>> and after analysis, I found that the casting of oop with “unsigned long”
>> makes that the two comparisons in:
>>
>>
>> if ((integerValue >= 0)
>>  && ((integerValue ^ (integerValue << 1)) >= 0)) {
>> object3 = ((integerValue << 1) | 1);
>> goto l12;
>> }
>>
>> always evaluates to true, no matter the value it receives.
>>
>>
>> btw the compiler warnings about this all the time, not just on
>> sendInvokeCallbackContext:… that’s why I wonder how this is possible to
>> work before :(
>>
>
> Maybe it was only working before because of the address range in which
> callbackContext occurred.  Maybe in el capital the stack is in a different
> place in memory and now it breaks things.
>
>> Esteban
>>
>>
>>> Esteban
>>>
>>> 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
>>
>> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151021/12c2e460/attachment.htm