<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-10-21 0:11 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 3:05 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><div><div><div><div><div>Doesn't the problem come from not respecting signedness when inlining?<br></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes great progress with type inference!<br></div><div>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.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div></div>Or from having incompatible type hint in caller/callee when inlining?<br></div></div></div></div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>Esteban warning comes from this:<br><br></div><div>the caller of positive32BitInteger: passed a usqInt (either by type inference or explicit pragma hint)<br></div><div>positive32BitInteger: expects a sqInt<br></div><div>inlining replace the sqInt parameter with the usqInt caller variable.<br></div><div><br></div><div>I say positive32BitInteger: should expect a usqInt<br> -- or maybe an unsigned int (32bits) - but this require further analysis for 64bits VM --<br></div><div>Because no sender will ever invoke positive32BitInteger: with a negative long...<br></div><div>I use this for 2 years now and it works well in 32bits stack/cog v3/spur and even in legacy interpreter vm.<br></div><div>I'll check again for 64bits VM<br><br></div><div>This case is an easy one, but there are more subtle traps for sure...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>If signedness differs, there the callee parameter should be inlined with a different variable and an explicit cast.<br></div>Most time, we should arrange to not have a signedness difference.<br></div>That's what I'm trying to achieve in my experimental branch.<br></div>But it's soliloquy..<br></div></blockquote><div><br></div><div>Well, if you're wrestling with this you know how difficult it is too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-20 23:59 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 2:54 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 20 Oct 2015, at 23:50, Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>> wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br>On 20 Oct 2015, at 23:35, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Hi Esteban,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano<span> </span><span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 20 Oct 2015, at 22:59, John McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>> wrote:</div><br><div><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></div></blockquote><div><br></div><div>I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :)</div><div>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 :)</div></div></div></blockquote><div><br></div><div>what's the context?</div></div></div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I spotted the problem when calling </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">sendInvokeCallbackContext:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">in concrete, when doing this: </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><span style="white-space:pre-wrap"> </span>self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).</div><div><br></div><div>positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).</div><div><br></div><div>and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:</div><div><br></div><div><br></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="white-space:pre-wrap"> </span><span style="color:rgb(187,44,162)">if</span><span> </span>((integerValue >=<span> </span><span style="color:rgb(39,42,216)">0</span>)</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="white-space:pre-wrap"> </span><span> </span>&& ((integerValue ^ (integerValue <<<span> </span><span style="color:rgb(39,42,216)">1</span>)) >=<span> </span><span style="color:rgb(39,42,216)">0</span>)) {</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="white-space:pre-wrap"> </span>object3 = ((integerValue <<<span> </span><span style="color:rgb(39,42,216)">1</span>) |<span> </span><span style="color:rgb(39,42,216)">1</span>);</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="white-space:pre-wrap"> </span><span style="color:rgb(187,44,162)">goto</span><span> </span>l12;</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="white-space:pre-wrap"> </span>}</div></div><div><br></div><div>always evaluates to true, no matter the value it receives.</div></div></div></blockquote><div><br></div><div>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 :(</div></div></div></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Esteban</div></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>Esteban</div><blockquote type="cite"><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano<span> </span><span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><span> </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>--<span> </span><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>===========================================================================</div></div></div></div></div></div></blockquote></div></div></blockquote></div><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></blockquote></blockquote></div></div></blockquote></div><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br></div></div>