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

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 20 22:11:18 UTC 2015


On Tue, Oct 20, 2015 at 3:05 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Doesn't the problem come from not respecting signedness when inlining?
>

This is really tricky.  It's really useful to have the inlined not enforce
signedness or unsignedness when inlining because that allows the types to
propagate through, which is most often what you want.  This gets even more
difficult when trying to make the code work for both 32-bits and 64-bits.
Right now Slang is poised "just so" and I have a working 32-bit and 64-bit
Spur system.  But it took a long struggle last year, a day of which I spent
with Bert at the CDG, to get it to work.

Or from having incompatible type hint in caller/callee when inlining?
>

That's more likely.  If the type must be specified then it must be
specified in the code with a type pragma.  The problem is that lots of the
time, the type must be specified very carefully.  One can't just cast to
(signed) because that actually means (signed int), which will truncate long
long, or 64-bit long values.


>
> 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..
>

Well, if you're wrestling with this you know how difficult it is too.


>
> 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
>>
>>
>
>


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


More information about the Vm-dev mailing list