I'm starting to think it would be worth writing a decompiler.
That's probably off-topic but, nevertheless, I'd like to comment on that.
Building a decompiler is an enormously hard task. If you wonder why please consider reading
https://www.hex-rays.com/products/ida/support/ppt/decompilers_and_beyond_white_paper.pdf by the author of the only working x86 decompiler today - Hex rays.
There are several other projects aiming for the same goal (RecStudio, Hopper Disasssembler), but they are mostly non-retargetable (do support only x86), inflexible, non-extensible and lack interactivity.
Bad thing, none of the existing decompilers can process PowerPC binaries.
I therefore wrote my own basic decompiler in Python that helps to keep manual work as minimal as possible. It is capable of performing data-flow and control-flow analysis, identifying common compiler idioms (function prologs/epilogs, switch statements, div instructions etc) and generating a basic C-like pseudocode consisting of reconstructed expressions inside of basic blocks.
It helps to collapse three PPC instructions into one statement on average - so it's much more than just a disassembler. It's a great time saver! You still have to use your brain and hands though. Anyway, it's a good start.
Moreover, it's possible to attach Python hooks to the processing, so several heuristics could be implemented really easily. For example, Trampoline calls OF with variable number of arguments. Fully automatic detection of such a stuff in the decompiler is almost impossible but, fortunately, you could write a function that will be called back for each "call" instruction and determine the number of inputs (2nd parameter) and outputs (3rd parameter) dynamically based on the service (1st parameter).
I'm working at cleaning up this Python beast for you to play with.