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

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


> 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 <mailto:estebanlm at gmail.com>> wrote:
>  
> 
>> On 20 Oct 2015, at 22:59, John McIntosh <johnmci at smalltalkconsulting.com <mailto: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.

Esteban



>  
> 
> Esteban
> 
> 
>> 
>> 
>> 
>> 
>> On Mon, Oct 19, 2015 at 9:31 AM, 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
>> 
>> 
>> 
>> 
>> 
>> -- 
>> ===========================================================================
>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk>
>> ===========================================================================
> 
> 
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

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


More information about the Vm-dev mailing list