MMX and SIMD opcodes

[Steve Rossell]

Recently technical support received an email from a user having problems with his code after executing some MMX instructions. I wanted to pass on this information to the community, so that you also do not encounter this same problem. When you execute an MMX or SIMD instruction (those that use MMX data), the FPU is placed in MMX state. You may then execute additional MMX or CPU opcodes. When you wish to exit MMX state and execute standard FPU opcodes, you must first execute an EMMS opcode. Failure to do so will result in floating-point exceptions or incorrect results.

[Gabor Toeroe]

Recently technical support received an email from a user having problems with his code after executing some MMX instructions. I wanted to pass on this information to the community, so that you also do not encounter this same problem. When you execute an MMX or SIMD instruction (those that use MMX data), the FPU is placed in MMX state. You may then execute additional MMX or CPU opcodes. When you wish to exit MMX state and execute standard FPU opcodes, you must first execute an EMMS opcode. Failure to do so will result in floating-point exceptions or incorrect results.

Is this still the case if you have a CPU with SSE?

[Steve Hutchesson]

Gabor,

No, the XMM registers are not shared with the FP unit so you don't have to worry about that one. The main trick when using XMM (SIMD) is making sure the processor supports the opcodes you are using.

[Gabor Toeroe]

Maybe it was asked somewhere else but I can't find a satisfying answer:

Does PB support SSE/MMX or do I have to put in my own ASM support for it?

Recently technical support received an email from a user having problems with his code after executing some MMX instructions. I wanted to pass on this information to the community, so that you also do not encounter this same problem. When you execute an MMX or SIMD instruction (those that use MMX data), the FPU is placed in MMX state. You may then execute additional MMX or CPU opcodes. When you wish to exit MMX state and execute standard FPU opcodes, you must first execute an EMMS opcode. Failure to do so will result in floating-point exceptions or incorrect results.

[José Roca]

Yes, it does. Read the help file, topic ASM statement.

[Steve Hutchesson]

Gabor,

The latest versions of PB support both MMX and XMM (SSE) opcodes but it is your responsibility to check if the processor supports those opcodes.

Steve's technical advice is due to the way PowerBASIC minimises the size of EXE code by using the floating point unit for a wide range of default arithmetic operations so if you use MMX specific instructions that in turn use the MMX registers you must reset the registers with EMMS so that you do not interfere with the default operations.

[Gabor Toeroe]

I meant if the compiled code contains sse/mmx instructions even if the source does not contain them (via inline ASM).

Gabor,

The latest versions of PB support both MMX and XMM (SSE) opcodes but it is your responsibility to check if the processor supports those opcodes.

Steve's technical advice is due to the way PowerBASIC minimises the size of EXE code by using the floating point unit for a wide range of default arithmetic operations so if you use MMX specific instructions that in turn use the MMX registers you must reset the registers with EMMS so that you do not interfere with the default operations.

[Steve Hutchesson]

Ok,

I have got what you meant. As far as I know from looking at a lot of PB code over time, NO. It would force every compiled program into having to have a proocessor detect built into it and multiple copies of algorithms for different processors.

The compiler provides the low level functionality to build programs and much of the code that it must provide to create executable code would not improve by choosing MMX or XMM instructions as it involves mainly interaction with the operating system.

The inline assembler is provided to be able to do the more advanced stuff that is processor model specific.