windows 64 patches that I got, can someone have a look?
---------- Forwarded message ---------- From: Roger Flores <aide...@yahoo.com> Date: Wed, Apr 10, 2013 at 9:02 PM Subject: Re: Windows 64 bit version To: Maciej Fijalkowski <fij...@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 <fij...@gmail.com> To: Roger Flores <aide...@yahoo.com> Cc: Amaury Forgeot d'Arc <amaur...@gmail.com>; matti picus <matti.pi...@gmail.com>; PyPy Developer Mailing List <pypy-dev@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 <aide...@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 > >
ptr_diff
Description: Binary data
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
