<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-07-18 19:03 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@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"><div dir="ltr"><div><div><div><div><div>The recipe for compiling on windows: install cygwin and pretend it's unix...<br>With Eliot's mvm scripts and gnu make, it's essentially same job on linux and macosx...<br><br>Note that gcc 4.9.3 -O2 does not perform a good job...<br></div>For example 2.0*3.0 answers 4.0 for the fast version (mvm -f).<br></div>All is correct for the debug version (mvm -d).<br><br></div>clang seems to be performing better, this means that we'll have to play with compiler options again...<br></div>Or better: eliminate Undefined Behavior which is most probably the cause of problems<br></div>(There is some in SmallFloat handling, shifting left negative int, pointer aliasing, etc...)<br></div><div class=""><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br>Note: i've
successfully compiled Squeak stack spur 64 bits with gcc 4.9.2 -02 and
restored the correct behavior for SmallFloat:<br> 2.0*3.0 correctly answer
6.0 instead of 4.0...<br><br>For that it's necessary to remove undefined behavior related to left shifting an unsigned integer.<br><br><div>Instead of generating something like:<br></div><div> ((sqLong) rcvr) << arg<br></div><div>It's better to generate it like this: <br></div><div> (sqLong)(((usqLong) rcvr) ) << arg)<br></div><br>This way we preserve signedness and Behavior is well defined.<br></div><div><div class="gmail_extra">Since
the formulation is rather heavy, I also added tricks to avoid some
casts if variable is long enough and unsigned already. If we later
switch longAt and some others as unsigned as already dicussed here, the
generated C might almost be readable.<br><br></div><div class="gmail_extra">I will commit the necessary VMMaker patch.<br><br></div><div class="gmail_extra">I've also replaced pointer aliasing<br> doubleResult = (double *)( & rawBitsInteger )[0];<br></div><div class="gmail_extra">by memcpy:<br></div><div class="gmail_extra"> memcpy( &doubleResult , &rawBitsInteger , sizeof(doubleResult) );<br></div><div class="gmail_extra"><br>Why is memcpy less evil than pointer aliasing?<br>With pointer aliasing any other write into a long integer could modify doubleResult.<br></div><div class="gmail_extra">This
completely defeat optimization - the holy grail of C people, they can't
bother that FORTRAN compilers are faster than theirs ;). With great
wisdom they declared this construct as undefined behavior, giving
priority to optimization rather than backward compatibility or
programmers' intentions...<br></div>memcpy is less evil because it's localized (one shot).<br><br></div><div>Nicolas<br></div></div></div></div>