When compiling code with VC++, MSDN gives you the option between using the x86_amd64 toolset or the amd64 toolset (when calling vcvarsall.bat).
How do I choose between those two when compile x64 code? Will the amd64 option churn out more efficient x64 machine code than the cross compiler?
It has nothing to do with efficiency. The native and cross-compiler will both generate the same machine code. You will however gain some benefits by running a native 64-bit compiler process on a 64-bit workstation (larger registers, larger memory space, etc...).
The native compiler will only run on an 64-bit copy of Windows, so if your workstation is 32-bit this compiler won't even run.
The cross-compiler is meant to run on x86 machines even though it will run on a 64-bit copy of Windows via WoW; however, there is no reason to do this.
The page you link says it quite well:
x64 on x86 (x64 cross-compiler)
Allows
you to create output files for x64.
This version of cl.exe runs as a
32-bit process, native on an x86
machine and under WOW64 on a 64-bit
Widows operating system.
x64 on x64
Allows you to create output
files for x64. This version of cl.exe
runs as a native process on an x64
machine.
Thanks to Brian R. Bondy for the quote formatting
From what you linked:
x64 on x86 (x64 cross-compiler)
Allows
you to create output files for x64.
This version of cl.exe runs as a
32-bit process, native on an x86
machine and under WOW64 on a 64-bit
Widows operating system.
x64 on x64
Allows you to create output
files for x64. This version of cl.exe
runs as a native process on an x64
machine.
Paraphrased:
If you use x86_amd64, then you are typically developing on an x86 machine and you want to create x64 files that run natively on x64. You could also use this option on an x64 machine but your compiler will be running under WOW64 emulation.
If you use AMD64, then you are developing on an x64 machine and you want to create x64 files that run natively on x64. The compiler is running natively in x64. This option is more efficient to build x64 programs.
You may wonder why you would ever develop an x64 program on an x86 computer, since you can't run it you can't debug it. Well it's still useful for example if you have a build server which is x86 and that build server needs to generate both x86 and x64 outputs.
How is it possible for a compiler to run under x64 if it is an x86 based program (x86_amd64)? That is the same reason you can run any x86 program on your x64 machine... Thanks to WOW64 emulation.
What is WOW64 emulation:
WOW64 emulation happens when you run an x86 program on an x64 computer (or IA64). WOW64 stands for Windows 32 on Windows 64. It is an emulation layer on top of x64 machines which allow you to execute x86 programs.
Your file system operations will be redirected to WOW64 folders and your registry will be redirected to a subnode as well. For example when you try to obtain the folder for program files it will return c:\program files (x86)\ if you are using WOW64 but it will return c:\program files\ if you are using x64.
Another example, for the registry if you try to write to HKLM\Software\Something it will really redirect you to HKLM\SOFTWARE\Wow6432Node\Something without your x86 program's knowledge.
Running a native x64 build will be more efficient than running through WOW64 emulation Why? Because you don't have that extra emulation layer of transforming your 32bit calls into 64bit ones.
By the way if you are running the x64 version of Windows you can see which processes are running through WOW64 because they will have a *32 appended to the process name in the process list.
Related
I develop and run some Fortran Code under Windows (7, 64 bit) using Visual Studio 2010 and ifort.
The code, mostly compiled to a DLL file, is tested on Windows and is deployed approx. 25% of the time to Windows (Windows 2000 up to Windows 7) and 75% to SUSE Linux. While the Windows solution is completely handled by me, the Linux "branch" is compiled by someone other (it is 100% the same code). The Linux branch is compiled with the g95/NAG compiler.
Due to some decisions out of our control, we will change from NAG to gfortran. After some tests, we found the code compiled with gfortran (and some optimisation like -o2) to take about double the time to finish compared to Windows and ifort (no optimisation, full debug). We had a chance to compile the code under Linux and ifort and got about the speed of Windows + ifort. (NAG compiled code is somewhere in between.)
For obvious reasons, we would like to compile the code with ifort for Windows and Linux, so:
Is it possible to compile for SUSE Linux under Windows with ifort (using cmd or Visual Studio 2010)?
I'll answer for Intel - no, you can't compile for Linux in Windows (except using a VM in which case you are really running Linux, as stated above). A VM is a reasonable approach, but you'll have to buy a separate license for ifort on Linux.
Or, as I assume you have a Linux box you will test on, build there (you can SSH to it from your Windows box.) True, you won't have the Visual Studio IDE, but some of our customers use Eclipse (with the Photran plugin) or Code::Blocks with Intel Fortran.
I'm looking for a way to builn a native 32bit exe on my 64bit developing machine.
Usually I would run: jx compile .\PhotoFly.jxp
But that produces a 64bit version.
Any ideas how to get the 32bit version?
To build a native 32bit app on 64bit platform, you should use jx compiled for ia32 processor.
If this is on Windows, you can either use the Windows Setup (x32/x64/SM/V8) (on x64 Windows you will have an option to install x32 JXcore binaries as well) or download the exact binary e.g. Windows 32 (V8) - all available on JXcore download page.
Then you can pack the app on 64bit Windows as usual:
> c:\path_to_jx_32\jx compile .\PhotoFly.jxp
I wrote an application in C++ for linux (X11, GLX) and it is working alright on my development computer (32-bit linux on 64-bit capable hardware). However, when I ran it on a 64-bit linux downstairs, I received an error telling me the linker failed to link stdlibc++.so.6, but I thought 32-bit compiled application could run on 64-bit kernels and Oses as well? At least that is the case in Windows... Do I have to separately compile 32 and 64 bit with different libs?
And how do I properly distribute my application? It's a game, and currently you have to run a makefile to let it move its dependencies to the /usr/lib/ directory (a kind of amateur installer). Will this work on all mainstream linux distro's? And are there better, neater ways to release your application?
I have a .NET application that runs on Linux, using Mono. I want to avoid users having to install Mono, so am using mkbundle. I am running mkbundle on an x86 machine, with the expectation of the resulting binary being able to run on x64 machines:
mkbundle MyApp.exe *.dll -o MyApp
I can then run the resulting application on the build machine with `./MyApp'
However, when I copy it to an x64 machine (and make it executable) it won't run, just outputting:
bash: ./MyApp: No such file or directory
If I try ldd I get:
not a dynamic executable
Shouldn't binaries built for x86 run on x64 systems?
I'm rather new to Linux, and it seems x86/x64 isn't quite as straightforward as it is on Windows, as many x64 Linux distributions don't ship with the capability to run 32-bit binaries.
After installing 32-bit libraries on the x64 machine, the x86 code will execute as expected (e.g. on Ubuntu 7.04, apt-get install ia32-libs.
While this works, as I need to target a number of distributions I've decided to just create separate builds for x86 and x64 instead.
How is Linux simultaneously 32bit and 64bit? Or is that something handled in glibc?
I run CentOS 5.3 and it is a "64 bit" version; although I build things for 64 bit and 32 bit. From what I think I know, Windows supposedly has a 32bit emulator. Does Linux do the same thing? Is it in userspace or kernel space?
If libc handles it, is it kind of like a emulator that says, I'll link with 32 bit apps, but speak 64 bit to the kernel?
The cpu can execute both 64 and 32bit instructions and the kernel can switch between modes. The only limitation is that you cannot link 32bit programs against 64bit libraries so you must have both 32 and 64bit versions of libc, etc. installed.
Nothing is stopping the cpu from switching from 64bit to 32bit. It just switches.
You can have a 64 bit kernel, and run 32bit apps. You can even have a 32bit kernel and run 64bit apps(Mac os x).
However you need the libaries they use to also be 32bit or or 64bit, which is why you might see files called lib64 or lib32 on linux for the 64bit or 32bit libaries.
Because x86_64 processors are designed over x86 technology, they are still able to support 32-bit programs without any hardware emulation, like what you would need to run x86 programs in a PowerPC or Sparc environment. In Linux, all you need to do is install the necessary software libraries to run the 32-bit software.