Just wondering if there's a bug in the "Store Pointer Address at" 4C001, according to the codetype docs:
4C0YZ00N XXXXXXXX
4C001 : [XXXXXXXX+grN] = po
If I have grN = 80123456, then the following would cause an exception:
4A000000 10101010 -- set po = 10101010
4C00100N 00000000 -- intended to store "10101010" at 80123456, but got a crash
E0000000 80008000
The reason for the crash is that instead of storing "10101010" at 80123456, it actually tried to store "10101010" at 80123456+80000000.
To test it adds an additional 80000000 to the address, I set grN = 00000080:
4A000000 10101010 -- set po = 10101010
4C00100N 00000000 -- store "10101010" at 80000080, no crash
E0000000 80008000
So, where does 80000000 come from? It would seem like the 4C001 codetype is effectively the same as 4C011 : [XXXXXXXX+ba+grN] = po... What's a proper way to store po at [grN] then?
1) show how you're setting grN
2) You can't store 32 bits at 80123456 because that's not aligned.
3) Proper way:
80000002 802468AC -- set gr2 = 802468AC //must be an address
4A000000 10101010 -- set po = 10101010
4C001002 00000000 -- [00000000+gr2's value (802468AC)] = po //so the address 802468AC now holds a value of 10101010
E0000000 80008000
That would make sense according to the codetype docs, but, in reality, I just got a crash when I sent that code ^
CR:40024202 XER:20000000 CTR:00000000 DSIS:06000000
DAR:002468AC SRR0:80002224 SRR1:00003032 LR:80001D4C
r0:80498D40 r1:805CE860 r2:8057E9C0 r3:00001002
r4:802468AC r5:00000001 r6:80000000 r7:80001808
r8:00000000 r9:802468AC r10:00000002 r11:00000000
r12:80000000 r13:80579440 r14:00000002 r15:800028D8
r16:10101010 r17:00000F80 r18:80002774 r19:00000000
r20:CC000000 r21:00000000 r22:00000019 r23:000000D0
r24:CD000000 r25:00001032 r26:80001810 r27:80002784
r28:000000FF r29:80001D4C r30:80001DA8 r31:80000000
80002224: 7E0C212E stwx r16,r12,r4
I don't really understand this, why do you set the pointer to a value instead of a valid address and wouldn't the 4C line just change the pointer to 802468AC overwriting the 10101010?
It's generally not a good idea to load non-address values into the po. It's like playing with fire. It is far more appropriate to load the data into a gr, and then use a 9421 to write the gr to the address in the po.
Looking at the crash registers, it seems like it's probably doing ba+X+grN. To confirm, I would set ba to 90000000 (42000000 90000000) before the 4C code, then get the crash again. If r12 is 90000000, then you're right, 4C001 will use the ba.
Well, I wanted to load a value to po because I wanted to use the DE code to check that value first, and save a line by combining both "if greater than" and "if less than" into a single line... but the lack of a 04/14 equivalence for [grN] has offset the benefits of the DE code. Oh well.
4C001 is the same as 4C011:
80000002 802468AC
4A000000 10101010
42000000 90000000
4C001002 00000000
E0000000 80008000
CR:42024282 XER:00000000 CTR:00000000 DSIS:06000000
DAR:102468AC SRR0:80002224 SRR1:00003032 LR:80001D4C
r0:80498D40 r1:80687D38 r2:8057E9C0 r3:00001002
r4:802468AC r5:00000001 r6:90000000 r7:80001808
r8:00000000 r9:802468AC r10:00000002 r11:00000000
r12:90000000 r13:80579440 r14:00000002 r15:800028E0
r16:10101010 r17:00000F80 r18:80002774 r19:00000000
r20:CC000000 r21:00000000 r22:00000019 r23:000000D0
r24:CD000000 r25:00001032 r26:80001810 r27:80002784
r28:000000FF r29:80001D4C r30:80001DA8 r31:80000000
80002224: 7E0C212E stwx r16,r12,r4
If you're paranoid about line count, you could always try to write a C0 code instead of standard code types. For moderately complex codes, it's possible to save one or two lines.