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

Esteban Lorenzano estebanlm at gmail.com
Tue Oct 20 21:37:08 UTC 2015


> 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 <mailto: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.
And with long long values (sqLong) always fit, so is also always true. 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151020/ca051b63/attachment-0001.htm


More information about the Vm-dev mailing list