4C001 codetype

[daijoda]

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?

[James0x57]

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

[daijoda]

That would make sense according to the codetype docs, but, in reality, I just got a crash when I sent that code ^

Code Select Expand


  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

[wiiztec]

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?

[dcx2]

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.

[daijoda]

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:

Code Select Expand

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

[dcx2]

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.