Buiding a windows DLL using tdm-MinGW

[Julio Jerez]

This is not true. MinGW supports DllMain just fine.
And MinGW can use .lib files for dll imports that are build by MSVC without problems.

Ha that was the problem, I added teh DLLMain and teh Main and now it does not crashes anymore.

But the dll is about 20 time slower than the window version, and I am usin teh same option that I am using in the Mac and Linux

gcc -c -Wall -Wno-strict-aliasing -D_MINGW_32_VER -msse -m32 -O2 -mtune=pentium4 -march=pentium2 -D_NEWTON_BUILD_DLL -Idg -Iphysics -o dg/dg.o dg/dg.cpp

teh only thing that is diffrent is teh version of GCC which is 4.4.1 here an din linux is 4.3.1 and in Mac is 4.2.0

gcc version 4.4.1 (TDM-1 mingw32)

It is lamost like the options are not doing anything because it is the same speed if I build in with -O0 option

gcc -c -Wall -Wno-strict-aliasing -D_MINGW_32_VER -msse -m32 -O0 -mtune=pentium4 -march=pentium2 -D_NEWTON_BUILD_DLL -Idg -Iphysics -o dg/dg.o dg/dg.cpp

[Julio Jerez]

Upps
the good new is that I was running with an old debug version, last nigth I undid the changes to the project and I was running with the last DLL with the option -g
the bad news is that release version still crashes on initilization.

[Marc]

maybe this helps? http://code.google.com/p/jrfonseca/wiki/DrMingw

[Julio Jerez]

For a debugger, you should probably go here: http://sourceforge.net/projects/mingw/files/ and grab the "GNU Source-Level Debugger".

But I download the whole Mingw package, and i see that it come with GBD, perhaps the worse tool ever made in the history of compiler tool,
I am afriad to touch the abomination that is GDB with a ten foot pole.
This is what I mean as to how arcane and draconian the Open source community really is.
It is going to be 2010 almost 40 years since we are making compilers and just about 99.999% of every developer in the world is using visual interfaces,
and here you have a tiny group of self appointed experts that opposes any kind of progress added to tools like GCC, GBC.

Why it is the GDB do not have a visual Interface? When will they make a decent tool that uses GCC with a visual interface on it?
Not only these people are obstructionist to progress they also excoriated any group who decide to make progress using these tools,
I can not count how many time I have to go in search for any tool to make up for this short coming of GNU tools just to find out that the have labeled "GNU do nor endorces or support this Tool".
Not only you see this in GNU you also see in the hundreds version of Linux, any one making a user friendly version get excoriated by the draconian making version like Red Hat Fedora and Mandrake.

[Julio Jerez]

maybe this helps? http://code.google.com/p/jrfonseca/wiki/DrMingw

Ok I installed this and I get the message that this debugger is defaul JIT debugger, then when I run teh test
I get the crash but when I click Cancel nothong happens.

Man, I did not know this was going to be so hard, I am bringging all the wierdness and Awkarness of Linux to windows for a few milisecund in performance.
I am about to give up on this.

[Julio Jerez]

I am biting the bullet and using dgb (what a worrible expericience) and it looks like the code to check the code is causing the crash, I am getting this

Program received signal SIGSEGV, Segmentation fault.
0x63a9892c in dgWorld::SetHardwareMode (this=0x100800, mode=1) at physics/dgWorld.cpp:362
362 m_cpu = dgGetCpuType ();
Current language: auto; currently c++
(gdb)

[Julio Jerez]

Well after I fixed the problem the DLL is working now,
I was using the code I use in the PC to detect SSE

Code: Select all

#if (defined (_MINGW_32_VER) || defined (_WIN_32_VER) || defined (_WIN_64_VER))
   static bool DetectSSE ()
   {
      __try {
         __m128 i;
         i = _mm_set_ps (dgFloat32 (1.0f), dgFloat32 (2.0f), dgFloat32 (3.0f), dgFloat32 (4.0f));
         i = _mm_add_ps(i, i);
         i = i;
      } __except (EXCEPTION_EXECUTE_HANDLER) {
         return false;
      }
      return true;
   }


   dgCpuClass dgApi dgGetCpuType ()
   {
      if (DetectSSE_3 ()) {
         return dgSimdPresent;
      }

      if (DetectSSE ()) {
         return dgSimdPresent;
      }
      return dgNoSimdPresent;
   }
#endif

But the exception failed in Mingw, now I changed to us the code I use for Linux GCC

Code: Select all

#if (defined (_MINGW_32_VER) || defined (_LINUX_VER) || defined (_MINGW_64_VER))

   #define cpuid(func,ax,bx,cx,dx)\
      __asm__ __volatile__ ("cpuid":\
      "=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (func));

   static dgInt32 i386_cpuid(void)
   {
      int a, b, c, d;
      cpuid(1,a,b,c,d);

      return d;
   }

   dgCpuClass dgApi dgGetCpuType ()
   {
      #define bit_MMX (1 << 23)
      #define bit_SSE (1 << 25)
      #define bit_SSE2 (1 << 26)

#ifndef __USE_DOUBLE_PRECISION__
      if (i386_cpuid() & bit_SSE) {
         return dgSimdPresent;
      }
#endif
      return dgNoSimdPresent;
   }
#endif

This works fine now, and that is the good new,
The bad news is that the DLL is about 10 times slower; it is taking about 70 millisecond in the same scene, while the VS take about 15 and the Intel takes about 9.
It seems the Intel is the best but the problem is that the Intel compiles doe no generate x87 code anymore. Or at least I do not know how to make it produce x87 code.
Well unless there is something else this give me closure. I do not know what make the code so fast in the Mac and Linux but the same compiler option is about 10 time slower in Windows with GCC.

[Marc]

Maybe the 4.4.1 does something differently than 4.3.x or 4.2.x and it's not working properly yet.

[agi_shi]

Try a static library just for testing. Perhaps the whole DLL business is having some weird effect on it.

[martinsm]

Are you sure you are building all .c/.cpp files (not just one) with -O2 option?

static bool DetectSSE ()
{
__try {
__m128 i;
i = _mm_set_ps (dgFloat32 (1.0f), dgFloat32 (2.0f), dgFloat32 (3.0f), dgFloat32 (4.0f));
i = _mm_add_ps(i, i);
i = i;
} __except (EXCEPTION_EXECUTE_HANDLER) {
return false;
}
return true;
}

I think this is pretty awful way of detecting SSE. You can use also cpuid instruction in MSVC with __cpuid() function: http://msdn.microsoft.com/en-us/library/hskdteyh.aspx
Because smart compiler should be able to optimize your code out, because result of it (i variable) is not used anywhere, so what's the point of executing it (from compiler point of view). To guarantee that compiler will not opimize memory access to variables you should add volatile keyword before type of i variable (volatile __m128 i).

[Julio Jerez]

Are you sure you are building all .c/.cpp files (not just one) with -O2 option?
I think this is pretty awful way of detecting SSE. You can use also cpuid instruction in MSVC with __cpuid() function: http://msdn.microsoft.com/en-us/library/hskdteyh.aspx

I know, but Visual studio does not allow assembly code in 64 bit mode, I have to uses intrisic and a excetion handlers.
I did not know there was a cpuid intrisic for visual studio, I will use that instead.
I would like to replace the fabs which in Vusual studio is such a horrendoues function and I use it a lot, I have to resolve to a simplers asm version in 32 bit and a C for 64 bit.
I you look at the code generated for fabs in VS you will die of a hard attack.
I will take a secund look to see if I can replace it back to the C version.

I do not really want to have a single line of assenbly code in the engine, and that is how it is very much for the 64 bit version and the Linux an dMac,
But in window 32 I have to do wierd stuff because the code compalitibility of Pentiun 2 setting and older AMD.
I thing I will up that to Pentium 4 or hightr.

Maybe I do like I do in the Mac, the Mac G3 do not handle Universal binaries, so I destribute libraries for Mac G3 separate,
Maybe for the PC I can just let the 2003 be the Lagacy build and VS 2008 be the best is can be.

and the -O2 option is a global rulle tha apply to all file. All file are compiled with the same option.

It is there a way to get CGG 4.3.1 for MingW?
I have seen these backward steps in GCC from version to version, I remember when going from 2.x to 3. 0 many functions that were perfectly fine sudthenlly GCC could no compile them,
stuff like 3.0 being slower than 2.8 in Play station two. It is a wierd world the GCC universe.

[martinsm]

You can get GCC 4.4.1 (and 4.3.3) versions for windows here: http://www.tdragon.net/recentgcc/
But I seriously doubt that it will change anything.

[Julio Jerez]

But I seriously doubt that it will change anything.

do you have any idea what coudl be?

I though the maybe the timer counter in Linux was wrong but that is not the case, if I add the option -ffloat-store the test code takes around 20 to 24 milisecunds per freame
if I just remove that option I get a litle over 5 milisecund per frame, I see similar results in the mac as well.
so even if the timer is wrong, the relative measurement cannot lie.
In the PC if I do the same thing the timer bar remains at the same high, so high that I have to change the scale so see something.

@Agi
how do I make the .lib, I have not found any information, on that?
The .a file can not be use like .lib files.

[martinsm]

I have no idea. Only thin that seems reasonable for me, that somewhere there optimizations are not enabled.
Try adding -ffast-math compilation flag, but that will affect only non FPU calculations, not SSE.

static libraries are made just by archiving all object files:

Code: Select all

ar q libNewton.a file1.o file2.o ... fileN.o

[Marc]

I have no idea how to convert a .a to a .lib, but if that is possible, maybe you can just use the linux .a to make a windows .lib out of it ...