Running 32-bit builds on a Win7 system

[TimSorbet]

Originally Posted by mdettweiler

Hmm...I didn't know there were such thing as dual-core i5's for desktops. I thought all the desktop i5's were quads, and that you had to go to i3 if you wanted a dualcore. But from the link you gave, it would almost appear that most of the desktop i5's out there are dualcores.

(Or is that not the whole list of desktop i5s?)

I think the i5-750 is more common than the rest.

[WraithX]

Originally Posted by ewmayer

- The 32-bit Windows build uses Visual-studio-style inline assembler for the SSE2 code (for gcc builds I have gcc-style macros, both 32 and 64-bit ... most of the latter attempt to take advantage of the extra 8 xmm registers to boost performance). But Microsoft being Microsoft, Visual Studio does not support 64-bit inline ASM. What is my best option for porting the assembler to a 64-bit windows build? Port the macros to 64-bit MASM, use 64-bit inline ASM with the Intel C compiler, what?

Have you heard about mingw-w64? It may be helpful for you. I've only done some very simple asm programming in it, but it did compile my 64-bit assembler statements. Here is the simple function that I was needing and that it compiled:

static u64_t mulmod64(u64_t a, u64_t b, u64_t c)
{
  u64_t d; /* to hold the result of a*b mod c */

  /* calculates a*b mod c, stores result in d */
  asm ("mov %1, %%rax;"   /* put a into rax */
       "mul %2;"          /* mul a*b -> rdx:rax */
       "div %3;"          /* (a*b)/c -> quot in rax remainder in rdx */
       "mov %%rdx, %0;"  /* store result in d */
       :"=r"(d)                 /* output */
       :"r"(a), "r"(b), "r"(c)  /* input */
       :"%rax", "%rdx"          /* clobbered registers */
      );
  return d;
}/* method mulmod64 */

Not sure how close that is to what you do, but it worked for me. Hopefully it could work for you too.

[ewmayer]

Originally Posted by WraithX

Have you heard about mingw-w64? It may be helpful for you. I've only done some very simple asm programming in it, but it did compile my 64-bit assembler statements. Here is the simple function that I was needing and that it compiled:
[snip
Not sure how close that is to what you do, but it worked for me. Hopefully it could work for you too.

Thanks for the tip - so that would allow me to build my GCC-ported ASM code (specifically the 64-bit version, since for 32-bit I can use the VS build) directly for Windows? That might be just the ticket - many thanks for the tip!

For the instruction-level profiling I mentioned I will still likely want to pay real $ for an Intel C license, but your suggestion should allow me to get a quick 64-bit build capability, so I can see how much of a performance difference the ASM using the full 64-bit-visible register set makes on my i7.

[ewmayer]

OK, I installed the current version of MinGW, added "C:\MinGw\bin" to my Windows path envvar, and tried a quick compile. The path update apparently doesn't take effect until the next restart, and I find it inconvenient to reboot just now, so for now I used the full path to the gcc binaries. The compile seems to succeed, but I see no object files created:

C:\Users\mayer\Visual Studio Projects\Mlucas\SRC>C:\MinGW\bin\gcc.exe -Wall -c br.c

...produces no .o or .obj files (or files of any kind) in the SRC directory. The compiler seems to be installed properly:

C:\Users\mayer\Visual Studio Projects\Mlucas\SRC>C:\MinGW\bin\gcc.exe -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --ena
ble-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror -
-build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

I also tried creating an executable using "gcc.exe br.c -o foo.exe", which should give an error message since that small source file contains no main and is not suitable for standalone build - again, no error messages, no files created.

Any ideas as to what may (or may not) be happening?

[WraithX]

Originally Posted by ewmayer

C:\Users\mayer\Visual Studio Projects\Mlucas\SRC>C:\MinGW\bin\gcc.exe -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --ena
ble-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror -
-build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

I also tried creating an executable using "gcc.exe br.c -o foo.exe", which should give an error message since that small source file contains no main and is not suitable for standalone build - again, no error messages, no files created.

Any ideas as to what may (or may not) be happening?

The first thing I think is happening is that you might not have the right compiler. There are 2 projects that share the mingw name. MinGW and MinGW-W64, where the first is solely for 32-bit binaries and the second can compile both 32 and 64-bit binaries. You can find the mingw64 project/files on SourceForge at:
http://sourceforge.net/projects/mingw-w64/

On the main page they have a source tarball where you can compile your own environment, or if you drill down into the all-files they have some precompiled toolchains available. If you go the precompiled route, I would recommend getting sezero's builds. If you are building -in- Win64 -for- Win64 I'd recommend the sezero personal build named: mingw-w64-bin_x86_64-mingw_20101003_sezero.zip Where mingw-w64 means your target is 64-bit windows; bin means it is precompiled; x86_64 is the host machine & OS, and mingw means the host OS is Windows. He also has personal builds if you want to cross compile 64-bit windows binaries from 32-bit and/or linux machines.

My gcc -v gives (I currently have an old version):

Using built-in specs.
Target: x86_64-w64-mingw32
Configured with: ../gcc44-svn/configure --target=x86_64-w64-mingw32 --host=x86_6
4-w64-mingw32 --disable-multilib --disable-nls --disable-win32-registry --prefix
=/mingw64 --with-sysroot=/mingw64 --with-gmp=/mingw64 --with-mpfr=/mingw64 --ena
ble-languages=c,c++
Thread model: win32
gcc version 4.4.3 (GCC)

You should be able to tell what compiler you are using from the "Target" information given in the gcc -v output.

If that doesn't work, or you already have mingw64, they have an excellent group of developers who are quick to respond to questions on their public mailing list located here:
https://lists.sourceforge.net/lists/...ngw-w64-public

[ewmayer]

Originally Posted by WraithX

The first thing I think is happening is that you might not have the right compiler. There are 2 projects that share the mingw name. MinGW and MinGW-W64, where the first is solely for 32-bit binaries and the second can compile both 32 and 64-bit binaries. You can find the mingw64 project/files on SourceForge at:
http://sourceforge.net/projects/mingw-w64/

On the main page they have a source tarball where you can compile your own environment, or if you drill down into the all-files they have some precompiled toolchains available. If you go the precompiled route, I would recommend getting sezero's builds. If you are building -in- Win64 -for- Win64 I'd recommend the sezero personal build named: mingw-w64-bin_x86_64-mingw_20101003_sezero.zip Where mingw-w64 means your target is 64-bit windows; bin means it is precompiled; x86_64 is the host machine & OS, and mingw means the host OS is Windows. He also has personal builds if you want to cross compile 64-bit windows binaries from 32-bit and/or linux machines.

Yep - I mistakenly thought MinGW and mingw-w64 were 2 versions of the same thing. Thanks for the personal-build links - got the one you mentioned, gcc -v shows

4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz]

...and a trial-build of the small file I tried previously shows it is working properly - in my case that means it is issuing a raft of predefine-related errors which tell me I need to modify my platform.h file to properly detect mingw64-for-windows.

Thanks, will post an update once I get something approaching a working 64-bit build of the SSE2-enabled code.

Weird thst the MinGW install looked like it succeeded, down to providing correct gcc -v diagnostics, but neither built anything nor issued any error messages indicating a problem.

-Ernst

[ewmayer]

Update: OK, things look promising: With a few tweaks to my platform-specific predefines (previously "OS = Windows" was treated as a euphemism for "Compiler = Visual studio"), I am able to successfully build all but a handful of files, and the failures are all files containing or referencing a handful of recently-written ASM macros which I have not yet ported to GCC format. A few evenings' work should get me there...

[ewmayer]

Up-update: Got one of the newer macros translated to GCC syantx, but while working out various issues with that, encountered something interesting ... I had been using a preprocessor block based on the value of the __LONG_MAX__ predefine to determine whether the OS was 32 or 64-bit. If __LONG_MAX__ was not defined, I instead examined sizeof(long).

That fails under mingw-w64 because even explicitly invokinh the -m64 compile flag, I see __LONG_MAX__ defined as 2147483647, which is the same as 32-bit mode under every "real" linux/GCC install I've ever used. At the same time I do see a __SIZEOF_POINTER__ = 8 predefine which I could use, but that is not predefined for any linux/GCC installs I've used up until now, so this gets messy.

Is doing something like sizeof(void *) safe, in the sense of being truly portable? That works fine in non-preprocessor (i.e. regular C) code, but the preprocessor does not like this:

#if(sizeof(void *) == 4)
	#define OS_BITS 32
#elif(sizeof(void *) == 8)
	#define OS_BITS 64
#else
	#error  Value of sizeof(void *) not recognized!
#endif

...it spits out

error: missing binary operator before token "("

Is there a simple, genuinely portable way of doing this detection at preprocessor time?

[rogue]

Originally Posted by ewmayer

Up-update: Got one of the newer macros translated to GCC syantx, but while working out various issues with that, encountered something interesting ... I had been using a preprocessor block based on the value of the __LONG_MAX__ predefine to determine whether the OS was 32 or 64-bit. If __LONG_MAX__ was not defined, I instead examined sizeof(long).

That fails under mingw-w64 because even explicitly invokinh the -m64 compile flag, I see __LONG_MAX__ defined as 2147483647, which is the same as 32-bit mode under every "real" linux/GCC install I've ever used. At the same time I do see a __SIZEOF_POINTER__ = 8 predefine which I could use, but that is not predefined for any linux/GCC installs I've used up until now, so this gets messy.

Is doing something like sizeof(void *) safe, in the sense of being truly portable? That works fine in non-preprocessor (i.e. regular C) code, but the preprocessor does not like this:

#if(sizeof(void *) == 4)
	#define OS_BITS 32
#elif(sizeof(void *) == 8)
	#define OS_BITS 64
#else
	#error  Value of sizeof(void *) not recognized!
#endif

...it spits out

error: missing binary operator before token "("

Is there a simple, genuinely portable way of doing this detection at preprocessor time?

sizeof() is evaluated by the compiler, not the pre-processor.

Look for LONG_MAX instead of __LONG_MAX__ (in limits.h). You should be able to do something like this:

#ifdef LONG_MAX
#if LONG_MAX == LLONG_MAX
#define OS_BITS 64
#else
#define OS_BITS 32
#endif
#else
#error WTF
#endif

[WraithX]

Originally Posted by rogue

sizeof() is evaluated by the compiler, not the pre-processor.

Look for LONG_MAX instead of __LONG_MAX__ (in limits.h). You should be able to do something like this:

#ifdef LONG_MAX
#if LONG_MAX == LLONG_MAX
#define OS_BITS 64
#else
#define OS_BITS 32
#endif
#else
#error WTF
#endif

Except that this doesn't work on 64-bit Windows systems. Win64 is an LLP64 type system, and Linux type systems are LP64. LLP64 means "long long" and pointers are 64 bits, but ints and longs are 32 bits. LP64 means longs and pointers are 64 bits, and ints are 32 bits. I found a nice graphic that shows the size of various types in a bunch of different OS's here:
http://www.alexkr.com/pics/ilp32.png

You might try to compare the size of a size_t which should be in SIZE_MAX (or __SIZE_MAX__). I'm not sure if this is standard across all gcc implementations, but size_t is supposed to be the same size as the pointer on any given system. I've found a list of some predefined macros on the gcc web site here:
http://gcc.gnu.org/onlinedocs/cpp/Co...ed-Macros.html

[rogue]

Originally Posted by WraithX

Except that this doesn't work on 64-bit Windows systems. Win64 is an LLP64 type system, and Linux type systems are LP64. LLP64 means "long long" and pointers are 64 bits, but ints and longs are 32 bits. LP64 means longs and pointers are 64 bits, and ints are 32 bits. I found a nice graphic that shows the size of various types in a bunch of different OS's here:
http://www.alexkr.com/pics/ilp32.png

You might try to compare the size of a size_t which should be in SIZE_MAX (or __SIZE_MAX__). I'm not sure if this is standard across all gcc implementations, but size_t is supposed to be the same size as the pointer on any given system. I've found a list of some predefined macros on the gcc web site here:
http://gcc.gnu.org/onlinedocs/cpp/Co...ed-Macros.html

I don't know if he is trying to determine the size of a long or the size of a long ptr as they are not necessarily the same. Using LONG_MAX and LLONG_MAX should work in Visual Studio, MinGW, and other OSes if trying to determine the number of bits in a long. If long ptr is what he care about, then LONG_MAX and LLONG_MAX will work everywhere except Windows, in which case he also has to include looking for WIN64. Without WIN64, long ptrs are 32 bits and with WIN64, long ptrs are 64 bits.

Note that the first line might need to be

#if (LONG_MAX == LLONG_MAX)

as parenthesis might be required by the pre-processor.