PowerPC For Dummies: A simplified guide to understanding the PowerPC Instruction Set

[JimmyKazakhstan]

I'm the type of person who has an extremely tough time learning complicated things unless every single aspect of it is explained to me in full detail. PowerPC Instructions being one of them, you would not believe the struggles I had trying to learn how the "load word zero" and "store word" instructions worked.

But the point is, a lot of other people have these issues as well. I know that there are a lot of people who have wanted to make codes for Wii games but stopped after not having any clue on how the instructions worked. Even some of the "simple" guides I have found are complex and assume you know exactly how it's supposed to work. Even some of the examples make no sense, to me at least. But I've spent a very long time trying to learn the very basic syntaxes of how some of the instructions work. And I've actually made a lot of progress. 

So I have put together a page called "PowerPC For Dummies". It's a page that lists a very large majority of the instructions and simplifies them to the point where (for the lack of a better sentence) even braindead individuals such as myself can understand!

Of course, it isn't done yet, but I have a fair amount of the first set complete. And I plan to add more instructions and examples to it!
I am posting it here because I thought that it could possibly help some people. (I'll be honest, even with the guides on this site, there are still some things I have trouble understanding).

I'm aware that the register order is often "rD --> rA, etc." but for the sake of simplicity the order on the guide is based on the order of the registers (ex: First Register in an instruction = Register A, Second = Register B, etc.)

Here is the link to the guide!
PowerPC For Dummies! - A Simplified PowerPC Instruction List

If anything in the guide is wrong, let me know and I will change it.

[WhatisLoaf]

Nice work! Assembly can be really tricky to wrap your head around when learning it for the first time.
I skimmed the page and I'd say there are a few things I would change:

- Under "Operation Terms", it's not the last bit that is checked, it's all of them. E.g. (011 AND 101) gives 001
- The definition of or OR should be "if at least one of the values is TRUE, the result is TRUE"
- ori does not load into the lower 16 bits, it OR's the lower 16 bits. E.g. if r1 contains 0xFFFFFFFF FFFF0000 and you do "ori r1, r1, 0xFFFF you'll get 0xFFFFFFFF FFFFFFFF

In general, you won't ever need most of these instructions, so I wouldn't worry to much if you don't understand all of them (I personally barely know maybe half of them)

[JimmyKazakhstan]

Nice work! Assembly can be really tricky to wrap your head around when learning it for the first time.
I skimmed the page and I'd say there are a few things I would change:

- Under "Operation Terms", it's not the last bit that is checked, it's all of them. E.g. (011 AND 101) gives 001
- The definition of or OR should be "if at least one of the values is TRUE, the result is TRUE"
- ori does not load into the lower 16 bits, it OR's the lower 16 bits. E.g. if r1 contains 0xFFFFFFFF FFFF0000 and you do "ori r1, r1, 0xFFFF you'll get 0xFFFFFFFF FFFFFFFF

In general, you won't ever need most of these instructions, so I wouldn't worry to much if you don't understand all of them (I personally barely know maybe half of them)

Thanks!

[Seeky]

"Pushes Data into a Stack frame to allow the use of Registers that normally can't be used for operations"
stwu is also often used for indexing by i in loops, I think it'd be better to just say it's stw but the resulting address is also stored to the address register

xoris isn't intended to be a copy, usually or rA, rB, rB would be used for that (with the mr instruction being a macro for that); xoris does a bitwise xor but with the immediate logically shifted left 16 bits first

[JimmyKazakhstan]

"Pushes Data into a Stack frame to allow the use of Registers that normally can't be used for operations"
stwu is also often used for indexing by i in loops, I think it'd be better to just say it's stw but the resulting address is also stored to the address register

xoris isn't intended to be a copy, usually or rA, rB, rB would be used for that (with the mr instruction being a macro for that); xoris does a bitwise xor but with the immediate logically shifted left 16 bits first

I should probably mention that most of the definitions are based on the results I got from using the instructions in dolphin and in assemblers, xoris always copied one register to another, so that's what I put, I'm not sure how I could simplify the actual definition though. 

But I will definitely update the definition of "stwu". Thanks!

[Vega]

Nice guide! Btw, here's an explanation of what eieio is...

Eieio is usually used with sync to create strict memory barriers. For Wii related stuff, it's used to ensure proper communication with the SEEPROM.

Normally, many different instructions can be executed out of order (such as load instructions)

Store instructions are always executed in order in when speaking in reference to each other but that doesn't mean they execute in order when referenced to non-store instructions. This is known as store gathering. Store gathering can be disabled by the Hardware Registers (HID0 - SGE bit), or you can use eieio (preferably immediately after your desired store instruction). Even if Store Gathering is enabled in HID0, eieio will prevent it.

example:
lwz rD, VALUE (rA) #Load Value from SEEPROM
sync #Wait for all instructions to finish before continuing <----start of memory 'barrier'
ori rD, rD, VALUE #Edit Value
stw rD, VALUE (rA) #Update New Value on SEEPROM
eieio #Prevent Store Gathering <----end of memory 'barrier'

---

Also, your definition and example for mr is incorrect.

Move Register actually copies a value from one register to another, A basic copy-paste, not a cut-paste.

mr is the simplified mnemonic for or (the register is just or'd with itself)

example:
mr r0, r1 = or r0, r1, r1

[JimmyKazakhstan]

Nice guide! Btw, here's an explanation of what eieio is...

Eieio is usually used with sync to create strict memory barriers. For Wii related stuff, it's used to ensure proper communication with the SEEPROM.

Normally, many different instructions can be executed out of order (such as load instructions)

Store instructions are always executed in order in when speaking in reference to each other but that doesn't mean they execute in order when referenced to non-store instructions. This is known as store gathering. Store gathering can be disabled by the Hardware Registers (HID0 - SGE bit), or you can use eieio (preferably immediately after your desired store instruction). Even if Store Gathering is enabled in HID0, eieio will prevent it.

example:
lwz rD, VALUE (rA) #Load Value from SEEPROM
sync #Wait for all instructions to finish before continuing <----start of memory 'barrier'
ori rD, rD, VALUE #Edit Value
stw rD, VALUE (rA) #Update New Value on SEEPROM
eieio #Prevent Store Gathering <----end of memory 'barrier'

---

Also, your definition and example for mr is incorrect.

Move Register actually copies a value from one register to another, A basic copy-paste, not a cut-paste.

mr is the simplified mnemonic for or (the register is just or'd with itself)

example:
mr r0, r1 = or r0, r1, r1

Thanks! I have a question though. Is "isync" the same as eieio? I wasn't able to tell based on it's description I found.

[Vega]

Not it's not. Eieio is the only instruction that is designed to effect store gathering.

Sync vs Isync

sync: Waits for all instructions to complete and no subsequent instructions are initiated until the sync itself has been completed. Also ensures memory accesses complete so other processors, mechanisms, and devices see the effects.

isync: Waits for all instructions to complete, but doesn't apply to memory accesses. Store gathering and out of order load/stores can still occur. Instructions after the isync are refetched and executed with whatever context (privilege, translation, protection) that was established by the previous instructions.

Basically sync is a memory barricade, while isync is an instruction barrier in lamest terms.

Sync is also used to wait for data cache updates/flushes/etc to complete, while isync is used to wait for instruction cache updates/flushes/etc to complete.

Regarding Wii codes, isync is used for self modifying code. Sync is not required because Broadway is a single processor with a single core and we don't care about other devices seeing the effects.

example:
lis r0, 0x4E80 #Example compiled instruction for a blr
ori r0, r0, 0x0020
stw r0, 0 (r4) #Write in new instruction to memory
dcbst 0, r4 #Clean data cache block. Push cache contents to physical memory
icbi 0, r4 #Whatever instruction(s) was in the instruction cache beforehand is invalidated
isync #Purge prefetched instructions, refetch. isync is not needed if first instruction of self modified code is at least 5 would-be executed instructions ahead. This because Broadway can only fetch up to 4 instructions at a time

At this point the new blr instruction in memory is there and will be executed if called upon

[JimmyKazakhstan]

Not it's not. Eieio is the only instruction that is designed to effect store gathering.

Sync vs Isync

sync: Waits for all instructions to complete and no subsequent instructions are initiated until the sync itself has been completed.

isync: Waits for all instructions to complete, however instructions after the isync are refetched and executed with whatever context (privilege, translation, protection) that was established by the previous instructions.

Basically sync is a full barricade, while isync is a partial barrier in lamest terms.

Sync is also used to wait for data cache updates/flushes/etc to complete, while isync is used to wait for instruction cache updates/flushes/etc to complete. I only know a little bit of Broadway's Cache model so there's definitely more to sync and isync than what I just explained.

Regarding Wii codes, sync and isync are used for self modifying code or to flush out the cache (as a whole) if a code is writing a new instruction to memory so another code will run the new instruction. If the cache isn't flushed, the old instruction may execute even though you see the new instruction in memory.

example:
lis r0, 0x4E80 #Example compiled instruction for a blr
ori r0, r0, 0x0020
stw r0, 0 (r4) #Write in new instruction to memory
dcbst 0, r4 #Update memory
sync #Wait for everything to complete, update the data cache
icbi 0, r4 #Whatever instruction(s) was in the instruction cache beforehand is invalidated
isync #Wait for instruction cache to be updated

At this point the new blr instruction in memory is there and will be executed if called upon

I'll be honest. I'm not sure if I fully understand it still, I had to look some other things up for it but I think I might have a basic understanding so far.
This is the list I've made for this, do I have the correct definitions?

dcbst = (Data Cache Block Store) = Writes a byte into the system memory. If you decide to use a register number for the first operand instead of the value "0", the code will write whatever is in Register B to the system memory.

icbi = (Instruction Cache Block Invalidate) =  Clears the system memory of the value stored by dcbst?

sync = (Sync) = Waits for every prior instruction within a function to be executed before it advances to the next instruction.

isync = (Instruction Synchronize) = Prevents code from advancing until the memory cache is changed/cleared?

[Vega]

No completely wrong. All those instructions have nothing to with 'code'.

For 99% of Wii codes you will never need these instructions. I wouldn't bother putting them in your simplified guide as these instructions are for more advanced work.