Assembly language is not widely known among the programming community these days, and PowerPC assembly is even more exotic. This article presents an overview of assembly language from a PowerPC perspective and contrasts examples for three architectures: ia32, ppc, and ppc64.
PowerPC Assembly Language
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This article is a nice try, but too short for any conclusions. Maybe it drives some interest for PPC asm.
Learning PPC asm is really easy, get the MPCFPE32B/AD document (aka Green Book) and read it.
These folks have been around for quite awhile, seems they’re closing the works.
Too bad, nice product.
FWIW
http://www.lightsoft.co.uk/Fantasm/fant.html
http://www.lightsoft.co.uk/Fantasm/Beginners/begin1.html
hylas
The article is extremely short.
The basic differences are obviously the fact that PowerPC uses fewer instructions than CISC processors and the PowerPC organizes data in the exact opposite manner regarding where the Least Significant Bit and Most Significant Bit are located when reading / writing / processing data when compared to x86.
(Little Endian data vs. Big Endian data)
Bit0, bit1, bit2, bit3, bit4, bit5, bit6, bit7 vs
bit7, bit6, bit5, bit4, bit3, bit2, bit1, bit0.
A better article would show basic routines and the pros / cons of each architecture and coding styles since they’re both so different–with some examples and speed vs code size metrics.
As someone who works with sparc and amd64 assembly
on a daily basis, this article did not really encourage
me to get ppc into my skull too.
(Nit: gcc still produces less-than-good sparc assembly
so it is definitely not a good tool to look at for learning
sparc).
There are two aspects to sparc which imho make it a
superior architecture to ppc from the programming
perspective: register windows and named registers.
Register windows allow you to avoid stack push/pop, and
since (on sparc at least) those windows slide around,
you can track back through the function call stack very
easily. When you’re doing crash dump analysis, this
counts for a lot!
Named registers allow the programmer and debugger (or
support engineer) to know exactly which register is
being looked at. From the article:
PowerPC registers have numbers, not names. For the learner, this can sometimes be confusing since literals aren’t easily distinguishable from registers. “3” could mean the value 3 or the register gpr3, or floating point fpr3, or special purpose register spr3. Get used to it.
Why should we have to just “get used to it” ? Even on
ia32/amd64 the registers have names. Overloading the
naming decreases understanding and clarity — we don’t
have to put up with it and it makes our jobs harder.
It’s also not apparent to me whether gcc’s output is
using the intel or AT&T assembler format — this makes
a huge difference to how we understand the code. The
author should have explicitly specified this.
The references list is good — if you want to get into
ppc, then you most certainly need these docs!
I wonder why this article is considered newsworthy. It was written in 2002.
> The basic differences are obviously the fact that
> PowerPC uses fewer instructions than CISC processors
Not strictly true. It has the same basic types of instructions as CISC processors. The big difference is the simplified addressing modes. Arthimetic and logical operations may only be performed on a register – you cannot directly operate on memory.
> the PowerPC organizes data in the exact opposite manner
> regarding where the Least Significant Bit and Most
> Significant Bit are located when reading / writing /
> processing data when compared to x86.
Yeah. But that’s just a naming convention. It doesn’t really matter which bit you call bit 0 and which is bit 31. It doesn’t really affect how you write code.
The fact that the PPC operates in big-endian mode by default and the x86 is always little endian is a much more significant difference.
I remember reading this article more than a year ago (or at least a very similar one from IBM)
> Why should we have to just “get used to it” ? Even on
> ia32/amd64 the registers have names
Isn’t the x86 the only current architecture that has named register as such (and even on the amd64 the extra registers are numbered)? PPC, Sparc, ARM, etc. all use numbered general purpose registers – because these registers really are general-purpose (well, r0 on the PPC isn’t). The x86 doesn’t have general-purpose registers in the same sense – and I always found that a pain.
And you can make your PPC code mode readable by naming registers “r0”, “r1”, etc rather then simply specifying them by number.
> Isn’t the x86 the only current architecture that has named register as such (and even on the amd64 the extra registers are numbered)?
Actually, the mips used named registers as well…you could address them by number if you desired ($0->$31), but there were friendly names such as $a0, $a1, $a2 (argument registers), $ra (return address), etc.
“There are two aspects to sparc which imho make it a
superior architecture to ppc from the programming
perspective: register windows and named registers. ”
Would you also say that the Sparc is a better architecture tnan PPC for one implimenting an object-oriented OS?
Would you also say that the Sparc is a better architecture than PPC for one implimenting an object-oriented OS?
I have no idea. I think an OO OS depends more on your
skills at actually designing it and implementing it
correctly than on a specific cpu architecture.
Of course, certain architectures could very well have
features which OO OS find useful and take advantage of,
but I think you will have a more powerful OS if you do
not depend on any such features.
> [snip about LSB/MSB]
>
>Yeah. But that’s just a naming convention. It doesn’t really >matter which bit you call bit 0 and which is bit 31. It >doesn’t really affect how you write code.
LSB and MSB sure does affect how you write code. If I store a 4 byte word to some address, the contents of individual byte addresses will be different…
> LSB and MSB sure does affect how you write code. If I
> store a 4 byte word to some address, the contents of
> individual byte addresses will be different…
That’s a difference in byte ordering.
What I was referring to is the naming convention for bits. This does not affect the ordering of bits. It’s simply that in PPC terms, the MSB in a word is known as bit 0 and the LSB is bit 31. The MSB is still 2^31. It’s just called bit 0.
How does MIPS assembly compare to PPC or SPARC? Easier to learn?
> How does MIPS assembly compare to PPC or SPARC?
> Easier to learn?
Definitely.
at last, James, someone who likes register windows! 😉
Would be nice if the other platforms would be covered as well.Instead of storings the shellcode in strings isn’t it more convenient to declare them inline with C++?
someone who likes register windows!
You would not believe how difficult it is to
learn crash dump analysis on sparc, get used
to finding function arguments courtesy of
register windows, and then have to futz around
on i386 with the stack and dereferencing…
Then of course on amd64 the function args go
into registers which — unless they get saved
somewhere (which is not mandatory) —
are almost gone forever!
How on earth is the poor benighted onsite engineer
supposed to figure out where the problem is on
amd64?
That’s where having good analysis tools
really helps.
Named registers allow the programmer and debugger (or
support engineer) to know exactly which register is
being looked at.
You can name registers on PPC and usually assemblers do name them. (Eg. gcc has -mregnames parameter.) You can use default names or even your own names for easier track of the use of a register. (Obviously this will not show up in a debugger, except if you used code inlining.)
The trouble comes from that if you mistyped something. Eg. you mix:
add r4,r4,r5
with
addi r4,r4,r5
Both will compile w/o error msg, but the first one is summing r4 and r5 registers, the latter one is incrementing r4 by the immediate of 5. I already ran into this several times.
Well the Sparc looks like a nice processor. Shame no one can put it in a EBX SBC form-factor.
Can you explain better how register windows work and why the method is better than using push/pop??
Register windows are better than push/pop for performance reasons. You’re not accessing main memory but just different “memory” positions inside the CPU. Way lot faster to pass parameters around.
For a description of register windows, maybe this can be of some help (just googled for it)
http://www.cs.tcd.ie/Martin.Emms/Logic/Sparc/SparcNotes/node
8.html
And yeah, knowing how to program in asm is good, but nowadays there are very few reasons to code directly in asm.
> Register windows are better than push/pop for performance reasons. You’re not accessing main memory but just different “memory” positions inside the CPU. Way lot faster to pass parameters around.
You “forgot” the drawback: register window implies a CPU more complicated to make than without this feature, slowing down (a little) the access to the registers..
Whether the performance increase of register window is worth the added complexity is hard to say..