Goal: writing an article with many examples, how POWER ARCHITECTURE friendly programming can be achieved. This involves a description, how architecture neutral coding can be achieved, and also some pointers, where POWER developers can be reached.
Target audience of the article: software developers, who write code without considering, that life exists outside the x86 architecture.
Participants: anyone willing to fix a few ugly software packages elegantly and / or document it for the article.
Background: recently I was recompiling many software packages originally packaged for x86 on my Pegasos, as a service for Pegasos users and the broader POWER community. This is the Packman (
http://packman.links2linux.de/ ) package collection for SUSE Linux / openSUSE. Some of the packages could not be recompiled for various reasons. For me (a non programmer) most of these were show stoppers, but even who can fix it must be annoying to see code, which does not compile without modifications on POWER ARCHITECTURE. Compilations were made from Packman source rpm-s, which might be a different version than the latest available sources.
The
problems and basic recommendations I identified are the following (sorry for the wording, I'm not a programmer):
Code:
- don't hard code architecture specific optimizations in Makefiles, like -mtune=i686 or similar, is it won't work on other architectures without modifications. If it really matters, make it conditional.
- if assembly is used to optimize code:
- find someone to do the same for PPC
- leave the original C code there as a fall back and as a sample, what has to be coded for other architectures
- never assume, that code will be compiled on i386, as it can cause trouble even on Opteron, and for sure on PPC and the rest of the platforms.
- don't use sys/io.h, as it's i386 specific, does not exists on other architectures.
This list is of course only partial, these were the problems which I met during compiles. This should be beefed up a bit with details and examples, and reworded for a programmer target audience.
ToDo:
Identify some software to fix. Good candidates are the one, which I failed to compile for Packman, but anyone can bring his / her own broken pet software :-)
Here is a partial list, those which I found useful after testing on x86:
i386 assembly:
cinerella:
http://heroinewarrior.com/cinelerra.php3
twindy:
http://www.niallmoody.com/twindy/
Broken Makefiles
soundtouch:
http://www.surina.net/soundtouch/ (many packages depend on it)
MuSE:
http://muse.dyne.org/
mixxx:
http://mixxx.sourceforge.net/
sys/io.h:
zinf:
http://www.zinf.org/
The next big task is to actually develop fixes for these software. Not just make it compile on POWER, but make sure, that it still can be compiled on the original platform (I can check that) and compile on POWER. And as the fix will be published in the article, make it elegant :-)
If a fix can't be made, document it why. If a fix can be made, document it how and why. It can be used as an example in the article and also sent to original developers. If you don't have time for coding, you can still help to pull all of these information together into one well written article!
Send patches upstream, so original developers recognize, that their code is used on other architectures and can support POWER later on without modifying source packages. And of course point them to the published (or working) version of the best practices article.
The end result will be published on
http://www.ppczone.org/
How:
For collaboration I would like to use the new PowerCollaboration.org environment. This has a wiki, which is ideal to collaboratively write the article, a file manager to store sources and patches, a forum to discuss problems, etc.
Please let me know if you would like to participate and I will add you to the collaboration software. If you have strong feelings against such a web based application, you can still participate, but that makes (at least my :-) ) life a bit more difficult.
Have fun while making POWER a better recognized platform!
Login
Register
FAQ
Search
)