The MMX registers should be using the same storage as the emulated FPU registers, otherwise they won't be saved/restored with fsave/frstor.

jmarsh wrote on 2020-06-23, 17:24:

The MMX registers should be using the same storage as the emulated FPU registers, otherwise they won't be saved/restored with fsave/frstor.

Fixed it, thanks for the heads up.
I also fixed EMMS handling, hoping this will work properly.

FYI, the Daum build, and by extension dosbox-x has had a cputype=pentium_mmx for a long time.

The MMX support in Daum is the "old patch" kekko referred to .

ripsaw8080 wrote on 2020-06-23, 20:32:

The MMX support in Daum is the "old patch" kekko referred to .

Indeed. Any build out there with mmx support use that old patch, thus none of them is actually working.

kekko wrote on 2020-06-23, 20:53:

ripsaw8080 wrote on 2020-06-23, 20:32:

The MMX support in Daum is the "old patch" kekko referred to .

Indeed. Any build out there with mmx support use that old patch, thus none of them is actually working.

Correct. It's currently known to cause the kernel audio mixing in Windows 98 to misrender 8-bit audio when using the MMX CPU type.

Also noted is that the way it's integrated technically allows MMX instructions in 386, 486, and Pentium CPU types even if CPUID doesn't report MMX extensions, which I consider a bug.

Another one I noticed is that the patch only implements MMX for 32-bit code. Either because the code segment is 32-bit or because a 32-bit override was given in 16-bit mode. At least from the Pentium MMX hardware I have it is legal to use MMX instructions in 16-bit real mode too.

TheGreatCodeholio wrote on 2020-06-23, 21:14:

Also noted is that the way it's integrated technically allows MMX instructions in 386, 486, and Pentium CPU types even if CPUID doesn't report MMX extensions, which I consider a bug.

I just added bit 23 to EDX. Is there something else? I haven't looked much into this.

TheGreatCodeholio wrote on 2020-06-23, 21:14:

Another one I noticed is that the patch only implements MMX for 32-bit code. Either because the code segment is 32-bit or because a 32-bit override was given in 16-bit mode. At least from the Pentium MMX hardware I have it is legal to use MMX instructions in 16-bit real mode too.

I added then removed this again. I thought it was not actually supported. I didn't check against actual hardware anyway.

kekko wrote on 2020-06-23, 21:38:

I just added bit 23 to EDX. Is there something else? I haven't looked much into this. […]
Show full quote

TheGreatCodeholio wrote on 2020-06-23, 21:14:

Also noted is that the way it's integrated technically allows MMX instructions in 386, 486, and Pentium CPU types even if CPUID doesn't report MMX extensions, which I consider a bug.

I just added bit 23 to EDX. Is there something else? I haven't looked much into this.

TheGreatCodeholio wrote on 2020-06-23, 21:14:

Another one I noticed is that the patch only implements MMX for 32-bit code. Either because the code segment is 32-bit or because a 32-bit override was given in 16-bit mode. At least from the Pentium MMX hardware I have it is legal to use MMX instructions in 16-bit real mode too.

I added then removed this again. I thought it was not actually supported. I didn't check against actual hardware anyway.

Normal software uses bit 23 of CPUID to check for MMX. What I'm saying is that the way it's integrated into normal core, MMX instructions can be executed for 486 and Pentium cores by programs that do not check CPUID properly.

16-bit real mode does indeed seem to support MMX instructions. Or else, 16-bit builds of the MMX test program in DOSLIB would crash when run: https://github.com/joncampbell123/doslib/blob … er/hw/cpu/mmx.c

On a related note, the Pentium III system I have on hand is also happy to support SSE instructions in 16-bit real mode as well, as demonstrated by this test program: https://github.com/joncampbell123/doslib/blob … er/hw/cpu/sse.c

All you have to do is set the bit in one of the control registers, and it works.

Thank you. Would you mind to make a patch?

kekko wrote on 2020-06-24, 06:32:

Thank you. Would you mind to make a patch?

16-bit real-mode MMX, yes?

TheGreatCodeholio wrote on 2020-06-24, 06:34:

kekko wrote on 2020-06-24, 06:32:

Thank you. Would you mind to make a patch?

16-bit real-mode MMX, yes?

Yes, please. For the other issue I added this at the beginning of each instruction:

1if (CPU_ArchitectureType<CPU_ARCHTYPE_PMMXSLOW) goto illegal_opcode;

kekko wrote on 2020-06-24, 06:38:

Yes, please. For the other issue I added this at the beginning of each instruction: […]
Show full quote

TheGreatCodeholio wrote on 2020-06-24, 06:34:

kekko wrote on 2020-06-24, 06:32:

Thank you. Would you mind to make a patch?

16-bit real-mode MMX, yes?

Yes, please. For the other issue I added this at the beginning of each instruction:

Copy code to clipboard

1if (CPU_ArchitectureType<CPU_ARCHTYPE_PMMXSLOW) goto illegal_opcode;

Here you go. Kind of hackish but it helps minimize changes to the code and avoids duplicating the MMX instructions. This is a recent DOSBox-X commit but I think it should be easily adaptable to SVN and other forks.

TheGreatCodeholio wrote on 2020-06-24, 06:44:

Here you go. Kind of hackish but it helps minimize changes to the code and avoids duplicating the MMX instructions. This is a recent DOSBox-X commit but I think it should be easily adaptable to SVN and other forks.

I just updated the patch in the first post. Thank you.

Wouldn't that cause SSE2 opcodes to be interpreted as MMX (since they are mostly the same with a 0x66 prefix) ?

I was looking for an efficient way to implement mmx instruction set to the dynamic recompiler when I found that someone made this addition to my patch
https://github.com/joncampbell123/dosbox-x/pull/290/files

seems quite fast, unfortunately it does not seem to work correctly in all cases (i.e. serious sam hangs right before showing titles, where interpreter works fine).
Do you see anything obviously wrong in it? I am not very confident with the recompiler

kekko wrote on 2020-06-24, 08:47:

I was looking for an efficient way to implement mmx instruction set to the dynamic recompiler when I found that someone made thi […]
Show full quote

I was looking for an efficient way to implement mmx instruction set to the dynamic recompiler when I found that someone made this addition to my patch
https://github.com/joncampbell123/dosbox-x/pull/290/files

seems quite fast, unfortunately it does not seem to work correctly in all cases (i.e. serious sam hangs right before showing titles, where interpreter works fine).
Do you see anything obviously wrong in it? I am not very confident with the recompiler

I personally don't, maybe it's something subtle. I'm not THAT familiar with the dynamic core.

The way I would go about it is to partially undo it piece by piece until you find the case where Serious Sam works again.

That usage of decode_fetchb_imm() looks suspicious, although unlikely to cause a problem unless it's a frequently modified instruction.

I am trying to save/restore host mmx regs <-> dosbox fpu regs, in order to be able to switch between recompiler and interpreter and comment out opcodes from the recompiler, until eventually I get the wrong instruction.
Any hint on how to perform this in the recompiler?