Just had a peek, that "return;" seems dubious, but I'm not sure though. Don't know
much about JIT.

else
{
	Default(inst); return;
	gpr.Lock(a, s);
	JitClearCA();
	gpr.LoadToX64(a, a == s, true);
	if (a != s)
		MOV(32, gpr.R(a), gpr.R(s));
	gpr.UnlockAll();
}

You mean i must add this code below the instruction?

What that code means is to disable the JITIL version of srawix and execute the
interpreter version. If you remove the "return;", you must also remove the
"Default(inst);" otherwise the results will be wrong.

Thanks, Autor.. I confirm that your information is correct and have had someone
validate it as well. I have this on my todo list, but please do not expect a fix soon.

Not sure how to fix this one. I noticed that the Jit64 version has an if check for
inst.SH == 0 and uses the interpreter in that case. This check is not performed by
JITIL. Below are the generated output from the JIT compilers for comparison.

JIT64 r5382 (working)¶

8001aa00: srawi r0, r26,2

Generated x86:
mov eax, dword ptr ds:[rip+0xeea78a0d]
mov esi, eax
sar esi, 0x02
cmp eax, 0x00000000
jnl .+0x0000000000000014 (0x0000000024152c5c)
test eax, 0x00000003
jz .+0x000000000000000c (0x0000000024152c64)
or dword ptr ds:[rip+0xeea78c71], 0x20000000
jmp .+0x000000000000000a (0x0000000024152c7a)
and dword ptr ds:[rip+0xeea78c65], 0xdfffffff
mov dword ptr ds:[rip+0xeea78977], esi
sub dword ptr ds:[rip+0xeee97d7c], 0x00000001
mov dword ptr ds:[rip+0xeea78be6], 0x8001aa04
jmp .+0xfffffffff19f69cc (0x0000000015b49685)

Binary x86:
8b050d8aa7ee8bf0c1fe0283f8007d14f7c003000000740c810d718ca7ee00000020eb0a8125658ca7eeffffffdf89357789a7ee832d7c7de9ee01c705e68ba7ee04aa0180e9cc699ff1cc

JITIL r5382 (not working)¶

8001aa00: srawi r0, r26,2

Generated x86:
mov esi, dword ptr ds:[rip+0xee86f351]
sar esi, 0x02
mov dword ptr ds:[rip+0xee86f2e0], esi
or esi, 0x7ffffffc
cmp esi, 0xfffffffc
setnbe cl
movzx edi, cl
cmp edi, 0x00000000
jz .+0x000000000000000c (0x00000000245659f8)
or dword ptr ds:[rip+0xee86f5a7], 0x20000000
jmp .+0x000000000000000a (0x0000000024565a0e)
and dword ptr ds:[rip+0xee86f59b], 0xdfffffff
sub dword ptr ds:[rip+0xeec8e6b8], 0x00000001
mov dword ptr ds:[rip+0xee86f522], 0x8001aa04
jmp .+0xfffffffff17ed308 (0x0000000015d52d49)

Binary x86:
8b3551f386eec1fe028935e0f286ee81cefcffff7f81fefcffffff0f97c10fb6f983ff00740c810da7f586ee00000020eb0a81259bf586eeffffffdf832db8e6c8ee01c70522f586ee04aa0180e908d37ef10f0bcc

Without computeRc in the end (makes it a bit hard to see the real code), and carry
marked:

Jit64¶

8b 05 28 64 30 01 8b f0 c1 fe 02 83 f8 00 7d 14 f7 c0 03 00 00 00 74 0c 81 0d a8 66
30 01 00 00 00 20 eb 0a 81 25 a8 66 30 01 ff ff ff df
0000000000000000 8b0528643001 mov eax, [rip+0x1306428]
0000000000000006 8bf0 mov esi, eax
0000000000000008 c1fe02 sar esi, 0x2
000000000000000b 83f800 cmp eax, 0x0
000000000000000e 7d14 jge 0x24
0000000000000010 f7c003000000 test eax, 0x3
0000000000000016 740c jz 0x24
-- carry --
0000000000000018 810da86630010000 or dword [rip+0x13066a8], 0x20000000
-0020
0000000000000022 eb0a jmp 0x2e
0000000000000024 8125a8663001ffff and dword [rip+0x13066a8], 0xdfffffff
-ffdf

JitIL¶

8b 3d 68 c5 57 00 c1 ff 02 89 3d 00 c5 57 00 81 cf fc ff ff 7f 81 ff fc ff ff ff 0f
97 c1 0f b6 f1 83 fe 00 74 0c 81 0d e8 c7 57 00 00 00 00 20 eb 0a 81 25 e8 c7 57 00
ff ff ff df
0000000000000000 8b3d68c55700 mov edi, [rip+0x57c568]
0000000000000006 c1ff02 sar edi, 0x2
0000000000000009 893d00c55700 mov [rip+0x57c500], edi
000000000000000f 81cffcffff7f or edi, 0x7ffffffc
0000000000000015 81fffcffffff cmp edi, 0xfffffffc
000000000000001b 0f97c1 seta cl
000000000000001e 0fb6f1 movzx esi, cl
-- carry --
0000000000000021 83fe00 cmp esi, 0x0
0000000000000024 740c jz 0x32
0000000000000026 810de8c757000000 or dword [rip+0x57c7e8], 0x20000000
-0020
0000000000000030 eb0a jmp 0x3c
0000000000000032 8125e8c75700ffff and dword [rip+0x57c7e8], 0xdfffffff
-ffdf

Loading appears to be the same, except that Jit64 keeps RS in eax for the carry-check
later on. JitIL inverts the check and stores 1 to edi when esi was above -4, while
Jit64 checks for eax (=RS)>= 0 and eax & 3 == 0.
JitIL is a bit hard to read, both the generated asm and the code itself, looks like
magu did a job optimizing (and obfuscating) it :o

I'm not exactly sure if that optimization to or/cmp/seta does exactly the same as
cmp/jge/test/jz.
But it does look interresting that Jit64 needs the result from earlier (esi) to do
some carry stuff, while JitIL does not.

ector, would you please shed some light into the difference in the generated ASM?

Anything on this one?
skid fixed (or at least made things go better) with r5790, altho OSX still seemed to suffer from something (around r5799).

Maybe close this one, if MGS is fine now, but open a new one that deals with the alignment issue (i guess) on OSX?

r5790 fixes issue 2187. This issue with the srawi instruction remains in JITIL.

nodchip, would you help us with this JITIL issue?

skidau: I want to help you however I don't have MGS Twin Snakes. If I get MGS Twin Snakes, I will check the problem.