mulps arithmeric exception

[GoogleCodeExporter]

Maybe I'm idiot. But right now almost every game I have (I have more than
10) crushed in 

mulps %xmm1, %xmm2

or

mulss %xxm0, %xmm5

and so on. 

But I could not understand -- it's SSE inctrucntions, and E8400 definitly
have no trouble with this. Could somebody help?

Original issue reported on code.google.com by Zeydl...@gmail.com on 20 Nov 2008 at 11:12

[GoogleCodeExporter]

BTW, all of this commands is SSERtoR or SSE_SS_RtoR results.

Original comment by Zeydl...@gmail.com on 21 Nov 2008 at 2:08

[GoogleCodeExporter]

I think it should be fixed in 355, but it does not.

Original comment by Zeydl...@gmail.com on 21 Nov 2008 at 9:47

[GoogleCodeExporter]

Pity. That's the bug that's been crashing the Linux 32 bit version the last 
dozen svn
versions or so. I'm still trying to figure it out, though. This workaround does 
avoid
the crash on my system[1], but it was intended to be temporary, till I figured 
out
why it was crashing.

[1] Though I did have to clear the Advanced settings back to defaults as I 
described
in the version. I'm getting awfully tempted to just hardcode mcxsr and disable 
the
advanced dialog for the time being...

Original comment by arcum42@gmail.com on 21 Nov 2008 at 9:59

[GoogleCodeExporter]

This registers changed by aVUzerorec.S. But why?

Original comment by Zeydl...@gmail.com on 21 Nov 2008 at 10:19

[GoogleCodeExporter]

I think that CustomConsecutiveFrames & CustomConsecutiveSkip being u8's instead 
of
int's in Misc.h is causing it. I'm still checking, though.

Original comment by arcum42@gmail.com on 21 Nov 2008 at 10:24

[GoogleCodeExporter]

Breakpoint 6, SuperVUExecuteProgram () at aVUzerorec.S:45
45          mov %eax, [%esp]
Current language:  auto; currently asm
(gdb) info registers mxcsr
mxcsr          0x9f20   [ PE DM ZM OM UM PM FZ ]
(gdb) c
Continuing.

Breakpoint 7, SuperVUExecuteProgram () at aVUzerorec.S:58
58          ldmxcsr g_sseVUMXCSR
(gdb) info registers mxcsr
mxcsr          0x9f20   [ PE DM ZM OM UM PM FZ ]
(gdb) c
Continuing.

Breakpoint 8, SuperVUEndProgram () at aVUzerorec.S:68
68          ldmxcsr g_sseMXCSR
(gdb) info registers mxcsr
mxcsr          0xffc0   [ DAZ IM DM ZM OM UM PM #13 #14 FZ ]
(gdb) c
Continuing.

Program received signal SIGFPE, Arithmetic exception.
0x0d2ba408 in ?? ()

Original comment by Zeydl...@gmail.com on 21 Nov 2008 at 10:24

[GoogleCodeExporter]

I give up. 356 does not help for me. Maybe it's a kernel trouble, cause I could 
not
trace any place that changes mxcsr except SetCPUState and aVUmicro.S code, but 
they
both work correctly.iVUmicro.c and x64 code does not worked for mxcsr change.

Original comment by Zeydl...@gmail.com on 21 Nov 2008 at 11:57

[GoogleCodeExporter]

Zeydlitz:
You can relatively safe remove any code that changes MXCSR at runtime.
See if doing that fixes your problem..

Original comment by ramapcsx2 on 21 Nov 2008 at 12:26

[GoogleCodeExporter]

rev 325 works -- rev 326 and so on no.

Original comment by Zeydl...@gmail.com on 21 Nov 2008 at 1:59

[GoogleCodeExporter]

Right, and that's when I started having issues. Revision 356 came about from me
reverting things in 326 until I stopped seeing MXCSR change between reading the 
ini
file, and recInit. 

Of course, it might not be a bad idea to delete inis/pcsx2.cfg, and let it be
recreated, just in case something in there is lingering.

Original comment by arcum42@gmail.com on 21 Nov 2008 at 2:18

[GoogleCodeExporter]

Issue 48 has been merged into this issue.

Original comment by ramapcsx2 on 23 Nov 2008 at 2:01

[GoogleCodeExporter]

Original comment by arcum42@gmail.com on 29 Apr 2009 at 9:09

• Changed state: Fixed