Hi Diana,

Answering you on the pypy-dev mailing list.  The question is about
Win64 support 

On 19 September 2016 at 14:34, Popa, Diana <diana.p...@intel.com> wrote:
> First of all, I started by translating PyPy on win64 with a hacked 2.7 Python 
> as described in the provided URL. I am encountering a problem when trying to 
> calculate MAX_DIGITS_THAT_CAN_FIT_IN_INT = rbigint.fromint(-sys.maxint - 
> 1).numdigits(). (...)

The URL doesn't describe what you are doing: it tells about hacking
Python 2.7, yes, but the next thing it says you should do is trying to
pass a specific subset of the tests.  There is no point in immediately
trying to translating PyPy.  But anyway, if you tried doing that, you
would hit the same problem immediately.  This is caused by the
"precision loss" I wrote about on that page.  I assume that sys.maxint
is equal to 2**63-1 in your hacked Python.  Then likely some
operations occur in C on this "long long" value that temporarily cast
the value to "long", resulting in precision loss.  You have to track
down what it is.  For example, start by writing some tests and put
them in rpython.rlib.test.test_win64:

def test_basic_arithmetic():
    def eq(x, y):
         assert type(x) is type(y) is int
         return x == y
    x = 2**50
    assert eq(x, 2**50)
    assert str(x) == "1125899906842624"
    assert str(sys.maxint) == "9223372036854775807"
    assert eq(sys.maxint, int(2**63-1))
    assert eq(x + x, 2**51)
    assert eq(x - (-x), 2**51)
    assert eq(x * 4, 2**52)
    assert eq(x | x, 2**50)
    assert eq(x >> 1, 2**49)

...as I guess that there is code a bit everywhere that depends on
that.  Fixing such failures is a matter of tracking down where CPython
stores things temporarily inside "long".

It is not necessary to get a perfect CPython that handles "long long"
systematically, but at least the basics like above should work.
Alternatively, you could try to globally replace "long" with "long
long" and similar.

A bientôt,

pypy-dev mailing list

Reply via email to