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

Tue Oct 20 23:12:59 UTC 2015

2015-10-21 0:11 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
>
>
> 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.
>
>
Yes great progress with type inference!
Maybe type inference should not prematurely freeze at method level: some
inlined methods might be generic (unless containing explicit type hint
pragma). It's like inference should take place in inlined code IMO.

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

Esteban warning comes from this:

the caller of positive32BitInteger: passed a usqInt (either by type
inference or explicit pragma hint)
positive32BitInteger: expects a sqInt
inlining replace the sqInt parameter with the usqInt caller variable.

I say positive32BitInteger: should expect a usqInt
 -- or maybe an unsigned int (32bits) - but this require further analysis
for 64bits VM --
Because no sender will ever invoke positive32BitInteger: with a negative
long...
I use this for 2 years now and it works well in 32bits stack/cog v3/spur
and even in legacy interpreter vm.
I'll check again for 64bits VM

This case is an easy one, but there are more subtle traps for sure...

>
>>
>> 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/20151021/260ae8e1/attachment-0001.htm