<div>
            <div>
                <span>Hi David, thanks for the quick response.<br>
                </span>
                <span></span>
                
                <!-- <p style="color: #a0a0a0;">On Tuesday, April 5, 2011 at 7:18 AM, David Schneider wrote:</p> -->
                <p style="color: #a0a0a0;">On Tuesday, April 5, 2011 at 7:18 AM, David Schneider wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div>Hi Liam,<br><br>On Tue, Apr 5, 2011 at 07:25, Liam Staskawicz &lt;<a href="mailto:lstask@gmail.com">lstask@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><div>Hi - I've been looking at pypy as a possible application runtime in an ARM9<br>Linux based system. I understand that the in-progress ARM jit backend<br>targets only ARMv7, but I'm still interested in characterizing a translated<br>pypy-c interpreter on this system with regard to CPU and memory usage. Of<br>course I look forward to possible ARMv5 support for the jit in the future,<br>but if I've understood correctly, fully interpreted mode should be supported<br>- please let me know if this is not correct!<br></div></blockquote><br>This is correct, the non-jitted version can be cross-translated to<br>ARM. Although it still only supports the Boehm GC so running PyPy<br>without the JIT will be slower than CPython. The JIT currently targets<br>the ARMv7 architecture, we have not tested on an ARMv5 processor yet,<br>but it would be interesting to see what is missing for compatibility<br>with ARMv5.</div></div></span></blockquote><div>I see - non-jitted is perhaps not such an interesting option at the moment then, I suppose. Are the other GC options not available because they rely on the jit, or is it another dependency?</div><div><br></div><div>I'll try to find some time to look into what's required for ARMv5 support. &nbsp;If you have any thoughts on particularly ARMv7-centric functionality in the current port that would need to be addressed, that would be interesting to know.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><br><blockquote type="cite"><div>To that end, are there minimum recommended system requirements for pypy,<br>specifically in terms of memory? &nbsp;As a reference, something like the Mono<br>'Small Footprint' wiki page applied to pypy would be what I'm looking<br>for:&nbsp;<a href="http://www.mono-project.com/Small_footprint">http://www.mono-project.com/Small_footprint</a><br></div></blockquote>At this point in time we have no official minimum requirements to run<br>pypy on ARM, but (quoting Armin) probably anything starting from 64MB<br>should be fine, depending on the application. The BeagleBoard which is<br>used to develop the ARM backend has 512 MB and pypy works fine on it<br>so far.<br></div></div></span></blockquote><div>OK, good to know - thanks!&nbsp;</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><br><blockquote type="cite"><div>On a related note, most of the build config info I've come across seems to<br>revolve around a scratchbox2 build environment targeting maemo - indeed it<br>seems to be the main other 'platform' option in the pypy build script, other<br>than 'host'. &nbsp;Is there any particularly tight coupling between maemo and<br>pypy, or should I hope to be able to set up a generic sbox2 environment for<br>my target and come away with a working build? &nbsp;Are there any other docs or<br>config snippets that detail how to set up a generic cross compile<br>environment for pypy?<br></div></blockquote><br>We used the scratchbox2 because it allows to create an environment<br>which can cross-compile programs, but also run small programs in a<br>context similar to the target environment. This is used to gather<br>information about the target, required for the translation.<br>For the ARM backend we are using an Ubuntu rootfs with the build-tools<br>installed and the gcc-arm cross compiler installed on the host. The<br>translation toolchain only needs to now the name of the sb2<br>environment in which to compile and execute the programs. One thing to<br>note is that the Python interpreter on the host must match the target<br>system in the sense of 32/64 bit. Besides these points any sb2<br>environment could be used to try the translation for a given target.<br></div></div></span></blockquote><div>Sounds good - I'll give it a shot. &nbsp;Thanks again.&nbsp;</div>
                
                <div>
                    <br>
                </div>
            </div>
        </div>