Just wondering about MMX

[bronxzv]

Its not obsolete, its been that since day 1. You seem to confuse what different OSes support. Windows do not support MMX/3Dnow!/x87 in long mode.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910(v=vs.85).aspx

this is a link about kernel mode, I mentioned explicitely user mode

btw it says that
"
In 64-bit versions of Windows, the operating system preserves the MMX/x87 registers across thread (and process) switches
"
in other words you just confirmed the official support in (today's) Windows


btw it works in front of me (x87 64-bit code on Windows 7), right now, just try it before to waste our time anymore

 

[ShintaiDK]

"
In 64-bit versions of Windows, the operating system preserves the MMX/x87 registers across thread (and process) switches
"
in other words you just confirmed the official support in (today's) Windows

Code that is produced by the 64-bit compiler for x64 processors does not use these registers and does not preserve them across function calls.

btw it works in front of me (x87 64-bit code on Windows 7), right now, just try it before to waste our time anymore

The 64-bit compiler for x64 processors automatically converts floating-point operations to SSE instructions.

Sure about that?

 

[bronxzv]

[/B]

Sure about that?

I don't use the MS compiler for code generation, so I can't tell, it has nothing to do with OS support, though

also note that an SSE3 instruction like FISTTP works with the x87 stack so that's not that easy to segregate the instruction sets

 

[ShintaiDK]

I don't use the MS compiler for code generation, so I can't tell, it as nothing to do with OS support, though

You dont use Intels either then.

 

[cytg111]

jesus friggin christ both of you ... it is not a fraggin piss contest. you are both right in your own way.
And here is the thing about arguing: (perhaps one day also on the internet) I would rather be corrected than being right. (just think about it)

 

[Schmide]

As I said, if you want x64+x87 you use Linux or another OS. To run x87 in Windows you need to run it in legacy mode.

Long mode in Linux is the same as Long mode on Windows.

The standard environment in 64bit windows is a 32bit space that is compatible with all extensions x87, mmx, sse(2), AVX etc.

It is the same for Linux. The new considerations are just for 64bit programs.

 

[bronxzv]

jesus friggin christ both of you ... it is not a fraggin piss contest. you are both right in your own way.

I don't see how both of us may be right on such a simple work / don't work topic, now I certainly wasted way too much time on it, I give up

 

[bronxzv]

Long mode in Linux is the same as Long mode on Windows.

The standard environment in 64bit windows is a 32bit space that is compatible with all extensions x87, mmx, sse(2), AVX etc.

It is the same for Linux. The new considerations are just for 64bit programs.

thanks, you reminded me that Windows 64-bit editions are always in long mode, also when runing 32-bit binaries in the compatibility sub-mode, so anyone can test legacy x87 binaries to see that they indeed work well in long mode

 

[jhu]

I don't use the MS compiler for code generation, so I can't tell, it has nothing to do with OS support, though

also note that an SSE3 instruction like FISTTP works with the x87 stack so that's not that easy to segregate the instruction sets

It's easy enough to see what the compiler is emitting. Just use a debugger to trace through the program and look for what types of floating point instructions are being used.

 

[cytg111]

It's easy enough to see what the compiler is emitting. Just use a debugger to trace through the program and look for what types of floating point instructions are being used.

I was gonna say "this. and do it myself..", but my favorite debugger olly, is 32 bit only .. you could go ida if have it (i dont .. the key).

 

[bronxzv]

It's easy enough to see what the compiler is emitting.

sure simply ask for an ASM output or a mixed ASM/source output from the compiler

the easiest test to prove ShintaiDK wrong in 64-bit mode will be to use MMX intrinsics since modern compilers avoid x87 code like the plague

 

[jhu]

sure simply ask for an ASM output or a mixed ASM/source output from the compiler

the easiest test to prove ShintaiDK wrong in 64-bit mode will be to use MMX intrinsics since modern compilers avoid x87 code like the plague

I've not used any Windows compilers, but gcc and icc on Linux allows explicit use of x87 and/or disuse of SSE in 64-bit code.

 

[bronxzv]

I've not used any Windows compilers, but gcc and icc on Linux allows explicit use of x87 and/or disuse of SSE in 64-bit code.

thanks, interesting, I suppose it requires special compilation flags (such as "fprecise") which are compiler specific, with the MMX intrinsics we will have a code that all peers can compile also with the MS compiler for 64-bit targets

if someone with a 64-bit compiler on Windows wants to try, just let me know and I'll devise and post a simple snippet

 

[BenchPress]

x87 and MMX instructions work absolutely fine in long mode (64-bit). bronxzv is right, ShintaiDK is wrong.

Just run this in Visual C++:

#include <windows.h>
#include <stdio.h>

static const unsigned char andn64[] =
{
    0x0F, 0x6F, 0x01,   // movq mm0, [ecx]
    0x0F, 0xDF, 0x02,   // pandn mm0, [edx]
    0x0F, 0x7F, 0x01,   // movq [ecx], mm0
    0xC3                // ret
};

int main()
{
    unsigned long oldProtection;
    VirtualProtect((void*)andn64, sizeof(andn64), PAGE_EXECUTE_READ, &oldProtection);

    __int64 a = 0x0102030405060708;
    __int64 b = 0x0807060504030201;
    ((void(*)(__int64*, __int64*))(void*)andn64)(&a, &b);

    printf("%I64x", a);
}