[Solved] PSP MIPS: addiu vs ori / How does addiu work?

[flame]

All MIPS instructions are 4 bytes, at least on 32-bit systems (i.e., PSP).
The MIPS instruction library is small because it is a RISC system.
The instructions are only 4 bytes. The immediate instructions (all of them) have an immediate value of 16 bits. The other 16 bits are needed to specify the instruction and target registers.
Pseudo-instructions are used by compilers to help you write your program more quickly.
li is a pseudo instruction that helps you load an immediate value in a target register. There's two implementations of li:

lui (load upper immediate) $t, value
ori (OR immediate) $t, $t, value
----------------------------
lui $t, value
addiu (ADD immediate unsigned) $t, $t, value
--------------------------------

Okay, so I was trying this in PPSSPP.
In the disassembly it says li at, 0x895E520.
Looking at the actual opcodes, it looks like:
lui at, 0x896
addiu at, at, 0xE520
It looks to me like that should add up to 0x896E520, but it actually adds up to 0x895E520.
------------------------------------

I did some tests in PPSSPP. I did:
lui at, 0x896
ori at, at, 0xE520
The result is 0x896E520.
-------------------------------------------
I also assembled an opcode:
addiu at, at, 0xE520
When I'm done assembling it, it looks like, in the disassembly view:
addiu at, at, -0x1AE0

Any idea what's going on?

[Gemini]

Addiu is still signed, no matter what. The difference between addiu and addi is that addi can fire an overflow exception.

[FAST6191]

Looks like Gemini sorted it. I I will go anyway

For the record RISC does not imply a small number of instructions in the instruction set but that those instructions within it will tend not to be the massively complex many cycle things that do a lot of almost higher level data manipulation (give or take some having SIMD stuff).

Also stylistically you tend to want to pad your hex numbers out -- 0x895E520 becomes 0x0895E520 . Mathematically it does not matter but in the spirit of avoiding problems last thing at night/after a long session or just so you can break it up when reading from left to right it is worth it.

Anyway afraid I do not know the PSP well enough to comment on what might be happening. I would agree that it looks like the compiler, disassembler or emulator is at fault unless there was something already in the register (if you are only adding and the lui does not wipe the lower). I also assume it is no coincidence that 0x1AE0 + 0xE520 = 10000 hex

[flame]

Well that was easily answered, wasn't it.
I think I get it now.

ADDIU instruction operation doesn't match its name "unsigned." It actually says that it's misnamed in the MIPS manual.