[pypy-dev] Fwd: Windows 64 bit version

[Maciej Fijalkowski]

windows 64 patches that I got, can someone have a look?


---------- Forwarded message ----------
From: Roger Flores <aidembb at yahoo.com>
Date: Wed, Apr 10, 2013 at 9:02 PM
Subject: Re: Windows 64 bit version
To: Maciej Fijalkowski <fijall at gmail.com>


OK, sorry this is going to be long.  The short version is I have
attached a diff for C files in rpython/translator/c handling long !=
ptr except for three files.




>It depends on the context. Essentially the approach is to run tests and figure out what's going on. Starting from rpython/translator/c

OK, looking around rpython/translator/c I see that there are C files.
Looking through there, I see cases where void * is being cast to
(long).  I started scoping out the extent of the change and realized
it was a finite set, not too huge.  So I decided to just make the
changes and send you diff so we can all just stop talking about it.
Then I realized that there were (unsigned long) cases.  And then
ulong.  And ULONG.  And ULLONG.  And so on.  Yes, I got sucked in.  In
the end I reviewed ALL cases involving "long", caseless.

The approach:
At first I quickly changed (long) to (long long).  Then I realized
that long long is 64 bits on 32 bit builds.  Either we need to 1)
conditionally compile each line of code based on the platform or 2)
use a type that we magically change once based on the platform.  Then
I noticed that ptrdiff_t is an existing type that is magically sized
correctly for all platforms.  So now (long) is (ptrdiff_t) with no
header changes.

The diff covers all C files.  It's not big.  I don't know the command
to run tests there so I didn't even check linux builds, let alone
win64, which I'm extremely reluctant to set up.  But what I changed
should be largely obvious.  In particular please review stack.c and
stacklet.c which used unsigned long and that might be an issue.

The three files I did not change are thread_pthread.c, dtoa.c and
obmalloc.c.  The changes are small but I didn't have high confidence.
obmalloc makes it's own ulong for some reason.


There are also python files.  I examined them for Long usage but
couldn't find a clear pattern.  Can you point out one example of what
needs changing?


>it would go in rpython/jit/backend/x86

I looked around but I'm going to need more direction.  I was
specifically looking for the linux and win32 portions to compare and
again, figure out the size of the change.  All I found though were
register descriptions and code to emit assembly instructions.



-Roger


________________________________
From: Maciej Fijalkowski <fijall at gmail.com>
To: Roger Flores <aidembb at yahoo.com>
Cc: Amaury Forgeot d'Arc <amauryfa at gmail.com>; matti picus
<matti.picus at gmail.com>; PyPy Developer Mailing List
<pypy-dev at python.org>
Sent: Tuesday, April 9, 2013 12:52 AM
Subject: Re: Windows 64 bit version

On Tue, Apr 9, 2013 at 9:47 AM, Roger Flores <aidembb at yahoo.com> wrote:
> Maciej Fijalkowski wrote:
>>It's just a bunch of work. There is nothing special or magic about it, but
>> so far noone volunteered to spend enough effort there.
>
> Got it. I'm just trying to understand what the work is because that list
> hasn't been captured anywhere yet.
>
>
>>Essentially, the main problem is that sizeof(long) != sizeof(intptr_t),
>> which is not a big problem per-se, it's just that this assumption has to be
>> removed from places in the RPython source code.
>
> OK. Could you find one or two of those places in the RPython source code so
> we can see?  And what is the fix?  Does long get changed to long long or
> another type or ?

It depends on the context. Essentially the approach is to run tests
and figure out what's going on. Starting from rpython/translator/c

>
>
>>Another one is the calling convention for the JIT, which is different than
>> on linux. Again, nothing special, just more work.
>
> Does "calling convention for the JIT" mean a function calling convention for
> 64 bit windows or something else?  Where is this in the code, or maybe,
> where is it for the Windows 32 code and where would the 64 bit version go?
> There's no magic for exceptions, gc, or anything else?

it would go in rpython/jit/backend/x86

>
>
> Thanks for the details,
> -Roger
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptr_diff
Type: application/octet-stream
Size: 4748 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/d77327ae/attachment.obj>