[pypy-dev] Fwd: Windows 64 bit version

[Armin Rigo]

Hi Roger,

On Fri, Apr 12, 2013 at 7:59 PM, Roger Flores <aidembb at yahoo.com> wrote:
> OK, this is really helpful.  It's exactly the kind of info I was hoping to
> hear when starting this thread, and what I was looking for on the web site
> before that.

I'm afraid to add that this list is not complete at all.  It merely
shows the points that we believe are the most sticky ones.

> 1. The size of long is different on Linux versus Windows, and that affects
> code that moves eight byte pointers to longs or back (see
> http://en.wikipedia.org/wiki/64_bit#64-bit_data_models).  Most of the C code
> has been reviewed and fixed by replacing the affected longs with ptrdiff_t.

The issue here is not really to fix the static C code (although we can
discuss if ptrdiff_t is really appropriate or ssize_t or intptr_t
would be better).  The issue is fundamentally that the RPython int
type should map down to a C type that is as large as a pointer.  It's
easy to change the C code generator to write "ptrdiff_t" instead of
"long" everywhere.  It's harder to convince all the places before, and
all the tests, that some number which is too large to fit the Python
type "int" should still be regarded as a 64-bit int.  This is because
we're going to run all this on top of a host Python which will
initially be CPython --- on which the "int" type is only 32 bits.  And
we assume left and right that the distinction between the CPython
types "int" and "long" is relevant, where in fact it is not.

For example, Christian Tismer started a few years back to do some of
the first changes; look e.g. at rpython.rlib.rarithmetic.intmask, and
the comments and docstrings before.  While I may disagree about a few
comments, he writes them, which is better than most :-)  I think that
the goal should be that the RPython program always considers the
Python types "int" and "long" as completely interchangeable (as if
we'd be running on Python 3), and uses if necessary rarithmetic.maxint
rather than sys.maxint.

> So it's download, get the dependencies (including pytest), translate
> (build), test, and then you're on your way.

That's wrong.  It's download, maybe get some dependencies (but *not*
pytest, which is included), and certainly *don't attempt to translate*
(no chance to get a useful result).  Just start running tests.  Don't
even attempt to translate the full PyPy until most tests pass (say,
most of the same ones that pass on Win32).


A bientôt,

Armin.