[Vm-dev] About my short term goals

[Nicolas Cellier]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160319/48c15650/attachment.htm