[Vm-dev] About my short term goals

[stephane ducasse]

> On 19 Mar 2016, at 16:57, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> 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.

Excellent I love that

> - 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

Excellent that too. 
I think that it will improve quality. 

> - simplify the slang source when possible

Would be nice. 
> - 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 <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 <https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun>
> http://hardwarebug.org/2010/01/14/beware-the-builtins <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 <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 is no problems about hiccups this is life.
there are problems not taming then with computer power and not engineer time. 

> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160319/dea588a7/attachment-0001.htm