Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Josh Aas writes: "I've been looking for a way to learn PowerPC assembly language for a while now. My search for books only led to extremely out-of-date publications, and the whole ordeal was generally frustrating. I was amazed at the lack of documentation. Even Motorola and IBM's documentation resources (on the web) were lacking anything of use to me. However, it turns out that Apple provides a pretty good free tutorial on the subject. It's tailored for coding in Mac OS X, but I imagine it would be just as useful in any PowerPC environment. For some reason it includes instructions for the Intel architecture. Perhaps this has to do with the fact that Darwin runs on x86 as well."

The real use of learning assembly is to validate your compiler output. It's rare to want to code much from the ground up in assembly anymore, save hardware-banging code, but knowing assembly still makes all the difference.

Yes, most compilers will perform 1,001 optimizations, but the final bit of optimization you can eck out demands that you profile, examine the hot points, and replace them with assembly or restructure your C with a good idea of the code you really want it to generate.

You'll still find things that the compiler engineers haven't thought of, or were lazy about implementing, or operations which implement unneccessary logic/precision.

For example, sometimes it's best to hoist an expensive calculation -into- a loop because it fits where the processor otherwise stalls, but most compilers take the opposite approach. It's tough to force a C compiler to do this, because most want to hoist code -out- of loops when possible, assuming it's cheapest.

Dependency on non-native signedness, float format or type sizes can mean that shifts, transcendental math, type conversion, etc is being done in software when a single opcode is what you expected.

Understanding the code will tell you if something unusual is happening, such as non-native sized bools or less than optimal variables being turned into register variables.

Some operations are simply not available to the C-only programmer. Subsequent lookups to sin/cos operations can be combined into a single opcode, but I've yet to see it done by any compiler. It's only available in assembly.

The PowerPC offers a rough inverse/division approximation which is faster than a real divide, and is good enough for operations only requiring low precision or an approximation... also completely inaccessible to C code.

Knowing a variable is guaranteed to be within a certain range or of a fixed set of values at a certain point can let you get away with all kinds of murderous assumptions which it's impossible to express in C.

That said, I haven't seen a single PPC assembler reference that was half as good as just looking at the code. Look at code, look at a lot of code, and past that, just look at system implementors' documentation. x86 through Pentium III aside, most current assembler books are just fluff, are wrong about half the pipelining, omit a million useful optimzations and don't cover the real story at all. It's really gotten to the point where the only real way to learn is by doing and doing and doing.

I'm working on an embedded PowerPC 603e and was able to find some descent documentation on the 32-bit PowerPC instruction set in general from Motorola's home page. I know you said you checked there, but I had a difficult time tracking it down myself. So in case you missed it, the name of the document is PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors [motorola.com]. I ordered a printed copy from their literature center, and a week later I got a nice little green book that has already proven to be indespensable.