Re: Porting parrot on PDA

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 <da...@perl.it>
> To: perl6-i...@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

~jerry