I just spent a couple of days studying and attempting to fix ppc64
support in the ocaml package.
OCaml is a nice, fast functional language. We carry ~ 70 OCaml-
related packages in Fedora. Since OCaml compiles to native code, it
needs a specific backend to be written for each target. Without this
it falls back to using a bytecode interpreter which is ~10 times
slower, so the backend is not required, but highly desirable.
Native code backends are not large nor especially hard to write. The
ppc64 backend in Fedora has just under 2000 lines of code. Moreover a
lot of that code is identical to the ppc (32 bit) backend.
Upstream, there are backends for many different architectures. Of
interest to this list, there is a backend for ppc (32 bit), and ppc64.
*However* the upstream ppc64 backend ONLY works on Mac OS X, because
it makes assumptions about the architecture and the assembler which
don't work with GNU as.
A long time ago, David Woodhouse wrote or modified a ppc64 backend,
which we are now carrying as a separate, non-upstream patch in Fedora.
It generally works, although it has several bugs, of which more later.
Upstream rejected this backend because they don't have the hardware
required to maintain it.
What I did
Because the ppc64 backend is so hard to maintain as a patch, I broke
it out into a git repository. This also makes maintaining other
patches easier (in particular my backport of the new ARM code
generator). If you need access to this, please request it in the
usual way via fedorahosted:
After doing this, I rewrote parts of our ppc64 backend so that they
more closely match the upstream ppc backend, ie. so that the
differences in the following commands are minimized as far as
diff -urb asmcomp/power64 asmcomp/power | less
diff -urb asmrun/power64-elf.S asmrun/power-elf.S | less
Note that I did NOT make any functional changes to the ppc64 backend
when doing this.
I also compiled a number of packages using our ppc64 backend. I
noticed that ocaml-camomile wouldn't compile. One module of this
program contains a very large "entry" function. The "entry" function
of a module is the name given to all the toplevel code in a module
which runs when the module loads and isn't a part of any function
definition in the module. By experimentation I found that when the
entry function exceeds around 26 kbytes, it causes corruption of the
minor heap. This is some sort of bug in the code generator, but I
wasn't able to determine what, and would appreciate any help in
I also found a variety of other bugs which all seem to be caused by
the smaller available default stack on ppc64 combined with the larger
number of registers (therefore more stack spillage). I will report
these upstream as I come across them, but the most serious is this
How I need help
I could do with help on #826649, particularly from ppc64 codegen
experts. Also on compiling any remaining ocaml-* packages on ppc64
(most already done) and checking that they actually function. Also on
identifying any remaining ocaml packages that have ExcludeArch: ppc64,
removing that and if necessary fixing any bugs found.
 I'm not precisely sure what assumptions it's making, and I could
be wrong on this point, but I certainly couldn't get the upstream
ppc64 backend to work on Fedora16/ppc64, and I also noticed the
assembler syntax is somewhat different from gas and incompatible.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.