<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 24/02/2020 10:52, Nicolas Cellier wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAKnRiT7HvAzN97THj_6K_epqmX3s9ZgKmr2pKfWJ3bUY1541dg@mail.gmail.com">
<pre class="moz-quote-pre" wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<div dir="ltr">
<div>Hi Pierre,</div>
<div>this complexity is incurred by C standard.</div>
<div>Standard committee decided that left shifting a signed integer was Undefined Behavior (UB).</div>
<div>Our program shall legitimately not depend on undefined behavior.</div>
<div>So the compiler has a license to presume that we didn't engage any operation resulting in UB.</div>
<div>This way, it can perform aggressive optimizations.</div>
<div><br>
</div>
<div>For example, if we write</div>
<div> sqInt foo (sqInt x) {</div>
<div> sqInt y = x << 15;</div>
<div> if( y < 0 ) {</div>
<div> return ~y;<br>
</div>
<div> }<br>
</div>
<div> }</div>
<div>Then the compiler can and sometimes will completely eliminate the if, because either y is a positive integer bit that overflows the sign bit, or y was negative, which both are UB.</div>
<div><br>
</div>
<div>Though, at machine level, with 2-complement, the left shift is perfectly well defined whatever signed-ness.</div>
<div>Yes, we might overflow the sign bit with a 0 in case of negative y.</div>
<div>But that's exactly the same condition as for positive y, we can overflow the sign bit with a 1...</div>
<br>
<div>Most of the time, what we want is signed left shift.</div>
<div>So we have first to convert to unsigned, shift, then convert back to signed integer.<br>
</div>
<div>So thanks to the standard, we now have to write completely stupid and illegible expressions like you can contemplate in OSVM...</div>
<div>Fortunately they are auto-generated, but unfortunately, it's a nightmare to decipher when reviewing or debugging generated code!</div>
<div>Maybe we could introduce some macro for legibility...<br>
</div>
<div><br>
</div>
<div>Nowadays, no one should program in C (and C++) without basic knowledge of UB, because it can strikes anytime, anywhere.<br>
</div>
</div>
</blockquote>
<p>Agreed. I'm aware of quite a few (thanks scott meyers !), but something that specific wouldn't have cross my mind !
<br>
</p>
<p>Thank you for the great explanation Nicolas !<br>
<br>
Pierre<br>
</p>
<blockquote type="cite" cite="mid:CAKnRiT7HvAzN97THj_6K_epqmX3s9ZgKmr2pKfWJ3bUY1541dg@mail.gmail.com">
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le lun. 24 févr. 2020 à 09:53, pierre misse <<a href="mailto:pierre_misse25@msn.com" moz-do-not-send="true">pierre_misse25@msn.com</a>> a écrit :<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>
<p>Hi all, <br>
<br>
I was thinking at first that this was already too complex for my neophyte mind, but I'd like to learn :)<br>
I'm not sure of why we use (sqInt)(((usqInt) x instead of (sqInt) x.<br>
Is it a way to do an absolute function to match Squeak semantics?<br>
I've also seen 3 different cast which looks a bit weird to me ˆˆ<br>
Thanks in advance !<br>
<br>
Pierre<br>
</p>
<div>On 23/02/2020 20:40, Eliot Miranda wrote:<br>
</div>
<blockquote type="cite">
<pre> </pre>
<br>
<fieldset></fieldset>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Feb 22, 2020 at 1:03 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" moz-do-not-send="true">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<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>Hi Eliot,
<div>What we must do is correctly infer the type that we generate.</div>
</div>
<div>Computing the type of (1 << anything) as int is correct if that is what we generate.</div>
<div><br>
</div>
<div>If it indeed overflows, then we must cast to VM word sqInt at code generation and indeed infer</div>
<div>(((sqInt) 1) << anything) as sqInt.</div>
<div>But this is invoking UB and potentially many -O compiler problems if left operand is negative.</div>
<div>So I think that we do generate this foolish (but recommended) expression:</div>
<div>((sqInt)(((usqInt) x) << anything))</div>
<div>and must we infer that type to sqInt. Maybe we have another path for constants...<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It appears we do all this. I'm reading (*my own?!) generateShiftLeft:on:indent: and it casts to 64-bits if appropriate and casts to unsigned and back if signed. It is the second most complex generation method, after generateInlineCppIfElse:asArgument:on:indent:.</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><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le sam. 22 févr. 2020 à 05:34, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank" moz-do-not-send="true">eliot.miranda@gmail.com</a>> a écrit :<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 dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Nicolas, Hi Clément, Hi Pierre, Hi All,
<div><br>
</div>
<div> I'm working again on ARMv8 having got confused and with help clear headed again. So I'm getting the real system to run (it displays the full desktop before crashing). One issue is the IMO mis-typing of #<<.</div>
<div><br>
</div>
<div>The expression in question is</div>
<div><span style="white-space:pre-wrap"></span>1 << (cogit coInterpreter highBit: cogit methodZone zoneEnd)</div>
<div>which is used to determine a type for mask:</div>
<div>
<div><span style="white-space:pre-wrap"></span>mask := 1 << (cogit coInterpreter highBit: cogit methodZone zoneEnd) - dataCacheMinLineLength.</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>In Smalltalk this evaluates to something large, and in the real VM it should evaluate to 1 << 39. However, because in CCodeGenerator>>returnTypeForSend:in:ifNil: we explicitly assume C semantics here:</div>
<div><br>
</div>
<div>
<div><span style="white-space:pre-wrap"></span>^kernelReturnTypes</div>
<div><span style="white-space:pre-wrap"></span>at: sel</div>
<div><span style="white-space:pre-wrap"></span>ifAbsent:</div>
<div><span style="white-space:pre-wrap"></span>[sel</div>
<div><span style="white-space:pre-wrap"></span>caseOf: {</div>
<div><span style="white-space:pre-wrap">...</span></div>
<div><span style="white-space:pre-wrap"></span>"C99 Sec Bitwise shift operators ... 3 Semantics ...</div>
<div><span style="white-space:pre-wrap"></span>The integer promotions are performed on each of the operands.</div>
<div><span style="white-space:pre-wrap"></span> The type of the result is that of the promoted left operand..."</div>
<div><span style="white-space:pre-wrap"></span>[#>>]<span style="white-space:pre-wrap">
</span>-><span style="white-space:pre-wrap"> </span>[sendNode receiver typeFrom: self in: aTMethod].</div>
<div><span style="white-space:pre-wrap"></span>[#<<]<span style="white-space:pre-wrap">
</span>-><span style="white-space:pre-wrap"> </span>[sendNode receiver typeFrom: self in: aTMethod].</div>
<div><br>
</div>
<div>we compute the ty<font face="arial,
sans-serif">pe of <span style="color:rgb(0,0,0)">1 <<</span><font color="#000000"><span> anything to be #int, and hence the type of mask to be int, and hence
mask is both truncated to 32-bits and later extended to 64-bits by virtue of being passed as an argument to a #sqInt parameter. So instead of generating the mask </span></font></font>16r7FFFFFFFC0 we generate the mask 16rFFFFFFFFFFFFFFC0. Clearly nonsense.</div>
<div><br>
</div>
<div>It seems to me that we have the wrong philosophy. In CCodeGenerator>>returnTypeForSend:in:ifNil: we should be computing types that cause the generated C to mimic as closely as possible what happens in Smalltalk, *not* typing according to the C99 standard,
which creates unintended incompatibilities between the simulated Slang and the generated Slang.</div>
<div><br>
</div>
<div>Surely what we should be doing for << is seeing if the right operand is a constant and if so typing according to that, but in general typing << as #sqInt or #usqInt, depending on the type of the left operand. This is what Smalltalk does; left-shifting
a signed value preserves the sign; left shifting a non-negative value always yields a non-negative value. Yes, eventually we will truncate to the word size, but the word size is sqInt, not int, and we are familiar with the truncation issue.</div>
<div><br>
</div>
<div>The mistyping of << as int is unexpected and extremely inconvenient. We force the Slang programmer to type all variables receiving the result of a << explicitly.</div>
<div><br>
</div>
<div>Do you agree or does my way lead to chaos?</div>
<div><br>
</div>
<div dir="ltr">
<div dir="ltr">
<div><span style="border-collapse:separate">
<div><font face="arial,
sans-serif">_,,,^..^,,,_</font><br>
</div>
<div style="font-size:small">best, Eliot</div>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>