[Vm-dev] About my short term goals

David T. Lewis lewis at mail.msen.com
Sun Mar 20 16:39:04 UTC 2016


Thank you very much for this explanation. You have been doing really
valuable work with numeric methods, and it is much appreciated.

In any bleeding edge development stream, occasional hiccups are to be
expected, expecially given the nature of the work that you are doing.
The fact that it happens so rarely is an indication of the quality of
your efforts.


On Sat, Mar 19, 2016 at 04:57:41PM +0100, Nicolas Cellier wrote:
> Hi,
> I feel like I did not explain my short term goals.
> This lack of explanation may let my recent commit be viewed as gratuitous
> breakage.
> They are not. What I'm after is:
> - reduce the number of C Undefined Behaviours that we depend upon
>   my own vm brand can be compiled without the -fwrapv workaround, it's
> doable.
> - eliminate ever more C compiler warnings
>   Eliot did really a great job these last two years
>   maybe we're not yet ready to compile with -Wall -Werror, but we are
> approaching
> - simplify the slang source when possible
> - connect the 32 bits limbs trick for accelerating large integer arithmetic
> About this last point, I'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.
> It's more robust and not really expensive nowadays.
> This way, the code that would fetch largeInteger bytes would still work
> unchanged.
> Also no need to hack ImageSegment and image version number.
> I'm thinking of using the approach of this kind of references:
> http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp
> https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun
> http://hardwarebug.org/2010/01/14/beware-the-builtins
> http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c
> So, once again, apologies for the hiccups, there might be a few more, even
> if I'll try my best to take it seriously and carefully, it's currently too
> expensive to guaranty non regression. With a single dev branch, it's more
> than expensive, it's impossible.
> Until we come with a more modern architecture, please don't consider that
> each and every monticello commit is OK to take as is.
> 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's not at each and every MC version.
> It's far from perfect, and maybe won't scale once a few more people add
> noise.
> But in the interim, my advice is to synch the production on .SVN release
> and associated MC version, not on MC.
> Running tests for the two are different jobs, that's a way to mitigate the
> fact that we have a single branch.
> cheers

More information about the Vm-dev mailing list