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

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 20 21:48:20 UTC 2015


Hi Esteban,

On Tue, Oct 20, 2015 at 2:37 PM, Esteban Lorenzano <estebanlm at gmail.com>
wrote:

>
>
> On 20 Oct 2015, at 23:28, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>> well… I solve the problem.
>> Everything is about the first issue report (comparison is always true).
>> I changed first from “unsigned long” to “sqLong” but then I realised
>> sqLong is defined as “long long” so this expression:
>>
>> intValue bitXor: (intValue << 1)) >= 0
>>
>> since number fitted in "long long”, was also always true. Then of course
>> it was converting into a SmallInteger a number that should be a
>> LongPositiveInteger.
>>
>> my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to
>> ensure parameter is “sqInt”.
>> That works.
>>
>
> No, you can't cast within  maybeInlinePositive32BitIntegerFor:.  That will
> break its use on long long values.
>
>
> but now does not work, because compiler says it is always true (any
> unsigned comparison to >= 0 will always evaluate to true for clang).
> Unsigned long is always >= 0.
>

Yes.  But if called with a saint it won't be. What's the context?  This
thing is used in lots of places.  Please tell me where you're finding the
problem.



> And with long long values (sqLong) always fit, so is also always true.
>

OK, so is what you're saying that

isIntegerValue: intValue
"Answer if the given value can be represented as a Smalltalk integer value.
In C, use a shift and XOR to set the sign bit if and only if the top two
bits of the given
value are the same, then test the sign bit. Note that the top two bits are
equal for
exactly those integers in the range that can be represented in 31-bits or
63-bits."
<api>
^self
cCode: [(intValue bitXor: (intValue << 1)) >= 0]
inSmalltalk: [intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]]

doesn't work for other than 32-bit values in clang?  Looks like this needs
to be smarter.  If it is called with squints then it is fine, but if called
with long long or unsigned long long we need to use the Smalltalk code:

    intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]

Slang can be (carefully) modified to do this.  But please, I need some
specific examples, not just "it doesn't work".  I need to know where it
doesn't work, because in many places it works just fine, and changing
things willy nilly is not the right thing to do (tm).


> I can of course ensure the type of parameter passed to
> maybeInlinePositive32BitIntegerFor before (not in the method). That will
> fulfil your requirement of not cast the function.
>
>
>
>> Now, I have this doubts:
>>
>> - how is possible this was working before? maybe this is a change in
>> clang 7 (apple)?
>>
>
> Unless we look in the debugger we won't know.
>
>
> I spent last 3 days doing it. #maybeInlinePositive32BitIntegerFor: was
> always “inlining”.
>
>
>
>> - now I have a lot of complains of “comparison of unsigned expression is
>> always true” all around the image. Should we take care about them?
>>
>
> Looks like it.
>
>
> So this is a major problem, I think… I will check.
>
> Esteban
>
>
>
>>
>> I will do some tests and commit to VMMaker tomorrow.
>>
>
> Don't just blindly commit a fix that makes clang 7 work.  It could easily
> break everything elsewhere.  Instead, we need to understand the issues
> first.
>
>
>>
>> cheers,
>> Esteban
>>
>>
>> On 19 Oct 2015, at 18:31, 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
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>


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


More information about the Vm-dev mailing list