Porting parrot on PDA
Aldo Calpini
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