<div dir="ltr"><div><div>The analysis I performed in 2013 was this one:<br><br>positive32BitIntegerFor: takes a positive 32 bit C integer, and make a Smalltalk integer object out of it (possibly a LargePositiveInteger in 32 bits VM)<br><br></div>The intention is clearly to pass a uint32 parameter, so the parameter must be unsigned and there is no point in testing if parameter is > 0.<br>AFAIR, all the send sites in VMMaker/plugins were in accordance with this, but I changed many type int in senders</div><div>I made this change and I had a working VM passing all the tests.<br><br></div><div><br>For 64 bits VM, this should probably be an unsigned int (not a usqInt which is too long).<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-20 22:59 GMT+02:00 John McIntosh <span dir="ltr"><<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">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? <div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div style="word-wrap:break-word"><div>Hi, </div><div><br></div><div>Does anyone tested Alien on Spur and "El capitan"? specifically callbacks?</div><div>For me, a completely broken :(</div><div><br></div><div>1) this structure (in maybeInlinePositive32BitIntegerFor: and others): </div><div><br></div><div><div><span style="white-space:pre-wrap"> </span>(integerValue >= 0</div><div><span style="white-space:pre-wrap"> </span> and: [objectMemory isIntegerValue: integerValue]) ifTrue:</div><div><span style="white-space:pre-wrap"> </span>[^objectMemory integerObjectOf: integerValue].</div></div><div><br></div><div>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. </div><div><br></div><div>2) <span style="color:rgb(120,73,42);font-family:Menlo;font-size:11px">assertCStackWellAligned </span>always fail. No idea why because if does not says anything, just jmp back to the regular flow. </div><div><br></div><div>3) finally, <span style="color:rgb(79,129,135);font-family:Menlo;font-size:11px">ceCaptureCStackPointers </span>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). </div><div><br></div><div>I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long. </div><div><br></div><div>But for 2 and 3 I have no idea where to start.</div><div><br></div><div>Does anyone has an idea?</div><div><br></div><div>Esteban</div><div><br></div></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">===========================================================================<br>John M. McIntosh. Corporate Smalltalk Consulting Ltd <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div></div></div>
</div>
<br></blockquote></div><br></div>