Starting from May 1 I leave my current job and I'm returning full time at university to work on my MSc project with PyPy. A FreeBSD 7.3 x86_64 buildbot from me is already available for the PyPy project. I also work under MacOS X (Snow Leopard) for my MSc project. I could probably help you for the particularities of these two platforms.<br>
<br>Keep me updated!<br><br>Gabriel Lavoie<br><br><div class="gmail_quote">2010/3/30 Maciej Fijalkowski <span dir="ltr"><<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Mon, Mar 29, 2010 at 9:12 PM, Jason Creighton <<a href="mailto:jcreigh@gmail.com">jcreigh@gmail.com</a>> wrote:<br>
> Hi Guys,<br>
><br>
> I am a student planning on applying to GSoC to create an x86-64 backend<br>
> for the JIT. I have a (very) rough draft of my proposal, and I was<br>
> hoping to get some feedback on it.<br>
><br>
> Specifically, I'm wondering about operating system support. I've written<br>
> the proposal as if I would support Linux/Mac OS X/Windows.<br>
<br>
</div>That would be great to have, but I would be happy enough to have it on<br>
linux. Let's say that if pypy continues to work on os x and windows<br>
you'll fix remaining 64bit JIT bugs.<br>
<div class="im"><br>
><br>
> I would be developing on Linux, so I think we can assume that would be<br>
> fairly well supported, but obviously I would like it to work on Mac OS X<br>
> and Windows as well. (I'm not sure if I would have the time/motivation<br>
> to care about obscure BSDs). OTOH, if there are already a lot of<br>
> outstanding issues on one of those platforms, I don't know that I would<br>
> be able to get it working. So what do you think would be a reasonable<br>
> goal here?<br>
<br>
</div>It's not like pypy works on anything else than linux os x and windows.<br>
<div class="im"><br>
><br>
> Secondly, my timeline is pretty vague. The PSF proposal template<br>
> recommends a week-by-week timeline, but honestly, I'm not sure how the<br>
> time usage would break down. Any comments on that would be greatly<br>
> appreciated.<br>
<br>
</div>I think week based planning is ridiculous. That may be done for some<br>
simpler stuff, but not for this. I would say have some milestones, but<br>
avoid precise timing.<br>
<div class="im"><br>
><br>
> Here's the draft:<br>
><br>
> === Proposal ===<br>
><br>
> The PyPy JIT, which has shown substantial performance improvements over<br>
> CPython, often several times faster, does not currently support the<br>
> x86-64 instruction set, making it impractical to use on 64-bit x86<br>
> systems.<br>
<br>
</div>and over unladen swallow.<br>
<div><div></div><div class="h5"><br>
><br>
> My proposal is to extend the existing x86 JIT backend to support x86-64<br>
> as well.<br>
><br>
> === Deliverables ===<br>
><br>
> Stable, tested 64-bit JIT for PyPy on Linux, Mac OS X and Windows merged<br>
> into PyPy trunk.<br>
><br>
> === Implementation plan ===<br>
><br>
> This is not a research proposal. The goal is simply to have a PyPy JIT<br>
> that works out of the box on 64-bit CPUs, implemented as conservatively<br>
> as possible.<br>
><br>
> As such, I will attempt to reuse as much of the existing x86 backend<br>
> that I can. In fact, the architectural similarities between x86 and<br>
> x86-64 are large enough that I hope to implement a unified x86/x86-64<br>
> backend with the majority of the code working for either platform.<br>
><br>
> There is an existing branch that, while very incomplete, has the<br>
> beginnings of a unified x86/x86-64 instruction encoding module. I intend<br>
> to use that branch as a starting point.<br>
><br>
> Rough outline:<br>
><br>
> 1. Take the existing "remove-ri386-multimethod-2" branch and use it as a<br>
> basis for instruction encoding.<br>
><br>
> 2. Port the existing 32-bit backend to use the new instruction encoding<br>
> scheme.<br>
><br>
> 3. Add 64-bit support to the backend,<br>
> A) Modify register allocator to use new general purpose and<br>
> floating point registers.<br>
> B) Port "ResOperation" operations to 64-bit<br>
> C) Port guard failure handling to 64-bit<br>
><br>
> 4. Test 64-bit on Mac OS X and Windows and fix inevitable issues.<br>
<br>
</div></div>There is also part about asmgcc.<br>
<div class="im"><br>
><br>
> === About Me ===<br>
><br>
> I am a first-year Computer Science student at Flathead Valley Community<br>
> College planning to transfer to Montana State University.<br>
><br>
> I have several years of professional development experience. I am<br>
> comfortable programming in Python, C and x86 assembly.<br>
><br>
> Starting May 17th, I will be able to commit 40 hours/week to the project<br>
> until the end of August. I may travel for a few weeks at some point in<br>
> the summer, but I will have a laptop with me with the expectation of<br>
> continuing full-time work.<br>
><br>
> === Contact information ===<br>
><br>
> Email: <a href="mailto:jcreigh@gmail.com">jcreigh@gmail.com</a><br>
> IRC: "jcreigh" on Freenode<br>
> Phone: (will be given on request, but not preferred)<br>
> _______________________________________________<br>
> <a href="mailto:pypy-dev@codespeak.net">pypy-dev@codespeak.net</a><br>
> <a href="http://codespeak.net/mailman/listinfo/pypy-dev" target="_blank">http://codespeak.net/mailman/listinfo/pypy-dev</a><br>
><br>
<br>
</div>Proposal is rather short, but I don't see how to expand it. You might<br>
want to add that in case you finish this stuff earlier you would do<br>
this and that (or just general JIT work or not do anything and drink<br>
beer).<br>
<div><div></div><div class="h5">_______________________________________________<br>
<a href="mailto:pypy-dev@codespeak.net">pypy-dev@codespeak.net</a><br>
<a href="http://codespeak.net/mailman/listinfo/pypy-dev" target="_blank">http://codespeak.net/mailman/listinfo/pypy-dev</a></div></div></blockquote></div><br><br clear="all"><br>-- <br>Gabriel Lavoie<br><a href="mailto:glavoie@gmail.com">glavoie@gmail.com</a><br>