Sounds interesting. I'm keen to port to maemo (Nokia N800) - I'm guessing this will be easier as it's based on debian linux and uses scratchbox for cross compilation, but I believe it doesn't built out of the box.
I'd like to join the porting effort if there's enough crossover to be able to help on this, cheerio, osfameron (sorry to break replyTo headers, I'm just newly resubscribed with this address)
message 36281 From: Aldo Calpini <[EMAIL PROTECTED]> To: perl6-internals@perl.org Date: Mon, 29 Jan 2007 18:36:08 +0100 Subject: Porting parrot on PDA hello people! I'm really interested in porting parrot to PDA (well, PocketPC at least). some days ago I stumbled upon CeGCC (a cross compiler for PocketPC), which is basically a windows port of gcc (both cygwin and mingw32 flavours) that produces ARM executable code. I started playing with it, trying to use it to build parrot; with just a few hours hacking, I managed to build a miniparrot.exe that actually runs (sort of) on PocketPC. I understand that what I've done is just a drop in the ocean, and that a real porting would require tons and tons of work more, but at least this first effort looks promising :-) now I will try to report briefly what I've done so far. I obviously started with "perl Configure.pl --ask", from a Cygwin bash shell. mainly, I told Configure to use "arm-wince-pe-gcc" instead of just "gcc" as the compiler, linker etc. and I disabled completely jit, threads and all the frills. of course, all the tests which relies on a test executable failed; they did compile indeed, but the executable couldn't be run on the desktop PC. that's the biggest problem, I suppose :-) so, I had to manually adjust lots of #define in config.h, has_headers.h, and later some minor fixes to feature.h, io.h and thread.h. I had problems with compiling src/stm/backend.c, turned out that the parameters to PARROT_ATOMIC_PTR_GET in atomic.h were reversed (this may be a bug not related to building with cegcc, I don't know); and ATOMIC_SET isn't defined, so I provided an optimistic (!): #define ATOMIC_SET(a,b) (a).val = b; I had to adjust also src/platform.c (the bits that come from config/gen/platform/generic/exec.c) because cegcc doesn't provide fork, execlp and waitpid. I used vfork, execvp and wait instead (I know, the last one isn't equivalent at all -- a problem for later!). at this point, miniparrot.exe was built. the process can't go much further because, obviously, that miniparrot doesn't execute on the desktop PC. anyway, I tried copying the executable on the device, and it does run! here's a transcript from my PocketConsole session: \CF Card\dada> miniparrot -h Couldn't create message pipe \CF Card\dada> something apparently didn't work with regard to thread handling. but it shouldn't be that hard to fix. the biggest problem, as mentioned, is that the build process needs fundamentally to execute stuff (built for the device, that is). this would require some serious hacking. IIRC, there are command line tools to copy and even execute files directly on the device. this would make possible to grab somehow the output and keep the build system happy. I will try, if I can, to search for a viable solution in the next days. if there's anybody else interested who wants to join the effort, let me know :-) cheers, Aldo
