<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi,<br></div>I feel like I did not explain my short term goals.<br>This lack of explanation may let my recent commit be viewed as gratuitous breakage.<br><br></div>They are not. What I&#39;m after is:<br><br></div>- reduce the number of C Undefined Behaviours that we depend upon<br></div><div>  my own vm brand can be compiled without the -fwrapv workaround, it&#39;s doable.<br></div>- eliminate ever more C compiler warnings<br></div><div>  Eliot did really a great job these last two years<br></div><div>  maybe we&#39;re not yet ready to compile with -Wall -Werror, but we are approaching<br></div>- simplify the slang source when possible<br></div>- connect the 32 bits limbs trick for accelerating large integer arithmetic<br><br></div>About this last point, I&#39;m now thinking about a different strategy for the hypothetical BIG-ENDIAN machines: swap bytes while fetching/storing limbs instead of using native order tricks.<br></div>It&#39;s more robust and not really expensive nowadays.<br></div><div>This way, the code that would fetch largeInteger bytes would still work unchanged.<br></div><div>Also no need to hack ImageSegment and image version number.<br></div><div><br></div>I&#39;m thinking of using the approach of this kind of references:<br><a href="http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp" target="_blank">http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp</a><br><a href="https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun" target="_blank">https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun</a><br><a href="http://hardwarebug.org/2010/01/14/beware-the-builtins/" target="_blank">http://hardwarebug.org/2010/01/14/beware-the-builtins</a><br><a href="http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c" target="_blank">http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c</a><br><br></div>So, once again, apologies for the hiccups, there might be a few more, even if I&#39;ll try my best to take it seriously and carefully, it&#39;s currently too expensive to guaranty non regression. With a single dev branch, it&#39;s more than expensive, it&#39;s impossible.<br><br></div>Until we come with a more modern architecture, please don&#39;t consider that each and every monticello commit is OK to take as is.<br>Eliot has short release cycles, and he does generally commit on .SVN repository when there is a MC version ready with enough added value and enough stability. That&#39;s not at each and every MC version.<br><br></div>It&#39;s far from perfect, and maybe won&#39;t scale once a few more people add noise.<br></div>But in the interim, my advice is to synch the production on .SVN release and associated MC version, not on MC. <br>Running tests for the two are different jobs, that&#39;s a way to mitigate the fact that we have a single branch.<br><br></div><div>cheers<br></div><br></div>