32-bit intel?

32-bit intel?

Michael M.'s picture

Hi, one of my developers is asking if there is a 32-bit Intel version of this package? We are only seeing Itanium 32-bit and Intel 64-bit....

-Michael

23 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Casey's picture

Yes, there is a ia32 version of the compiler.  If you have a license for the compiler you can download it in the intel registration center (there are 64 bit / 32 bit and combined packages for the compiler (32 bit x86 is the "ia32" version and 64 bit x86_64 is the "intel64" version).

Random aside:  I'm guessing you were probably confusing the "ia32" nomenclature for itanium, which could be confusing since Itanium is "IA64", but as far I know there is no such thing as 32 bit itanium and the "ia" label just makes note that it is Intel's instruction set.  The non-itanium 64-bit instruction set is EMT64/AMD64 which coms from AMD who stuck to an x86 compatible insturction set while intel diverged toward the itanium.

Jennifer J. (Intel)'s picture

Casey is correct. We do have the compiler for IA-32. Meaning a compiler to genreate ia32 binary. Please check the "readme.txt" to see detail component info in the package. e.g. see this readme.txt. or you can google for other readme.txt.

The 13.x compiler pkg does not have the compiler for Itanium architecture or IA64 any more.

Jennifer

Sergey Kostrov's picture

>>...The 13.x compiler pkg does not have the compiler for Itanium architecture or IA64 any more...

I know that version 8.1 has Intel C++ compiler for Itanium architecture ( take a look at Update 038 ). I understood that at some point Intel "frozen" that direction and I do not know if versions 9.x, 10.x or 11.x have the compiler in installations.

Release Notes for version 8.1.038 are attached.

Attachments: 

Tim Prince's picture

There never was an Itanium 32-bit mode compiler.  Intel compilers for Itanium "IA64" are available up through version 11.1.  The gyrations Intel marketing went through trying to choose a name for what became "Intel64" didn't help with the goal of differentiating it from the terms "AMD64" X64 and x86_64 which have overlapping usage.

Sergey Kostrov's picture

>>...x86_64...

I saw that macro many times in Intel headers and what is exact meaning / goal of so confusing __x86_64 macro? Microsoft, MinGW and Borland don't use it at all.

Casey's picture

Did Borland ever produce a 64 bit compiler?

To answer your question Sergey, GCC and GCC-like compilers define the __x86_64__ macro if you are building a 64 bit AMD / intel (non-itanium)  target.

To demonstrate:

1 #include <stdio.h>
 2 
 3 int main()
 4 {
 5 printf("__x86_64__ is ");
 6 #ifndef __x86_64__
 7 printf("not ");
 8 #endif
 9 printf("defined\n");
10 
11 return 0;
12 }

$ gcc -m64 -o test test.c 
$ ./test
__x86_64__ is defined 
$ gcc -m32 -o test test.c 
$ ./test
__x86_64__ is not defined 
$ icc -m64 -o test test.c 
$ ./test 
__x86_64__ is defined
% pgcc -m64 -o test test.c 
% ./test 
__x86_64__ is defined
$ clang -m64 -o test test.c
$ ./test
__x86_64__ is defined
$ clang -m32 -o test test.c
$ ./test
__x86_64__ is not defined

I don't have the 32 bit intel or pgi compilers installed, but the result would be the same as the 32 bit gcc testcase.

Compilers used: icc 13.1.3 20130607, pgcc 11.9, gcc 4.6.3 and clang 3.3.  

Sergey Kostrov's picture

>>Did Borland ever produce a 64 bit compiler?..

It looks like No before 2000 year ( around these times it moved to Delphi and C++ Builder but with a different company name ). Here is their final notice for the C++ compiler:
...
..\BCC55\Bin>bcc32.exe
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Syntax is: BCC32 [ options ] file[s] * = default; -x- = turn switch x off
...

>>...I don't have the 32 bit intel compilers installed, but the result would be the same as the 32 bit gcc testcase.

I will check and report results your testcase with a 32-bit MinGW v3.4.2. However, this is how Intel uses that macro:

[ Example 1 - xmmintrin.h ]
...
#if defined ( __x86_64 ) || defined ( _M_X64 )
extern __int64 __ICL_INTRINCC _mm_cvtss_si64(__m128);
...
#endif
...

[ Example 2 - tbb_stddef.h ]
...
# if defined ( _M_X64 ) || defined ( __x86_64__ ) // the latter for MinGW support
# define __TBB_x86_64 1
# elif defined(_M_IA64)
...

[ Example 3 - tbb_machine.h ]
...
#elif __i386__
#include "machine/linux_ia32.h"
#elif __x86_64__
#include "machine/linux_intel64.h"
#elif __ia64__
#include "machine/linux_ia64.h"
...

As you can see two variants of macros are used, that is __x86_64 and __x86_64__. In two cases it is the same as _M_X64 ( for a 64-bit platform only ).

Casey's picture

The __x86_64 and __x86_64__ macros are equivelent as far as I can tell.  You can modify my test case to check for the other version and the results are the same for all compilers I mentioned.  The intel headers will use them to include architecture specific code and additionally they are there for your use as well if you have any arch dependant code   The _M_(ARCH) style macros are those defined by MSVC and the inclusion of both styles lets any compiler include those intel include files with the proper architecture specific code.  You can see more examples of these macros at use in the linux kernel, which handles code for many architectures.

Sergey Kostrov's picture

>>...The _M_(ARCH) style macros are those defined by MSVC...

I don't think that _M_ stands for Microsoft and it stands for Machine. I consider that notation ( a Microsoft-like ) as more neutral and this is how it is used on a project I work for ( however, the project is highly portable and isolated from Microsoft's Win32 API for 99.99% ):

...
// HRT Abstraction Layer Declarations - Processing Units Dependent
// Macros for Vendor Processing Units:
//
// INTEL _M_IX8616 ( 16-bit )
// INTEL _M_IX86 ( 32-bit )
// INTEL _M_X64 ( 64-bit )
// AMD _M_AMD64 ( 64-bit )
// INTEL _M_IA64 ( 64-bit Itanium )
// ARM _M_ARM
// SH _M_SH
// MIPS _M_MRX000
// ALPHA _M_ALPHA
// POWERPC _M_PPC
// MOTOROLA _M_M68K
//
// Note: A universal term Processing Unit is used instead of CPU, APU or SOC

#if defined ( _M_IX8616 )
#pragma message ( "*** Message: Compiling for Intel Processing Unit ( 16-bit ) ***" )
#endif
#if defined ( _M_IX86 )
#pragma message ( "*** Message: Compiling for Intel Processing Unit ( 32-bit ) ***" )
#endif
#if defined ( _M_X64 )
#pragma message ( "*** Message: Compiling for Intel Processing Unit ( 64-bit ) ***" )
#endif
#if defined ( _M_AMD64 )
#pragma message ( "*** Message: Compiling for AMD Processing Unit ( 64-bit ) ***" )
#endif
#if defined ( _M_IA64 )
#pragma message ( "*** Message: Compiling for Intel Processing Unit ( 64-bit Itanium ) ***" )
#endif
#if defined ( _M_ARM )
#pragma message ( "*** Message: Compiling for ARM Processing Unit ***" )
#endif
#if defined ( _M_SH )
#pragma message ( "*** Message: Compiling for SH Processing Unit ***" )
#endif
#if defined ( _M_MRX000 )
#pragma message ( "*** Message: Compiling for Mips Processing Unit ***" )
#endif
#if defined ( _M_ALPHA )
#pragma message ( "*** Message: Compiling for Alpha Processing Unit ***" )
#endif
#if defined ( _M_PPC )
#pragma message ( "*** Message: Compiling for PowerPc Processing Unit ***" )
#endif
#if defined ( _M_M68K )
#pragma message ( "*** Message: Compiling for Motorola Processing Unit ***" )
#endif
...

Note: _M_IX8616 is the project's internal macro defined for all 16-bit platforms.

Casey's picture

I never claimed the M stood for Microsoft, only that those are the macros that MSVC defines.  If you want code portable between MSVC(-like) and gcc(-like) compilers you need to be checking both the MSVC style (_M_(ARCH)) and gcc style (__(ARCH)__) macros.  

Sergey Kostrov's picture

>>...gcc style (__(ARCH)__) macros...

GCC-like macros are not used at all.

Casey's picture

Zitat:

Sergey Kostrov schrieb:

>>...gcc style (__(ARCH)__) macros...

GCC-like macros are not used at all.

Not used by whom?  Perhaps not by your example (which I can plainly see) but I was not speaking directly to your sample and instead generally on how handle architecture dependant code in a portable way.  Whether it is directly applicable to you isn't important, the message is the generality of the concept so that others stumbling upon this threads off topic divergence can benefit from it.

Sergey Kostrov's picture

>>...Not used by whom? Perhaps not by your example (which I can plainly see) but I was not speaking directly to your sample and
>>instead generally on how handle architecture dependant code in a portable way...

I explained it and gave the example. I don't see any reason of changing some core pieces of codes ( to support some questionable GCC-like macros ) on the project and re-starting a complete re-testing, re-verification, etc phases of a software development cycle. If you support at least more than one platform on a project you work for you're free to use whatever you, or your team, wants.

Casey's picture

Sergey, 

I think we are having a misunderstanding, lets get on the same page.  I never told you to do or change anything in your code or project or otherwise.  You initially posed the question as to the purpose of the __x86_64 macro, which I provided an answer and some details on.  You keep countering my answer with your own project code, but that does not change the answer.  Whether you use the gcc style macros or not (and I do not care whether you do or not), does not change thier purpose.

For reference, the question I was addressing is:

>> what is exact meaning / goal of so confusing __x86_64 macro?

And to re-iterate the answer: It is to allow the portable compile-time inclusion of intel64/AMD64 specific code on GCC and GCC-like compilers. (Includes but is not limited to GCC, Intel, Portland Group and LLVM compilers, as demonstrated by example)

Sergey Kostrov's picture

>>...__x86_64

It is the most illogical macro in GCC-world I've ever seen. A developer who created the macro __x86_64 doesn't understand that x86 stands for a 32-bit platform and 64-part stands for a 64-bit platform. He "fused" these two parts ( abbreviations ) together in one macro by unknown reason.

A message to Michael M:

Michael,

I'm very sorry for that very long deviation from the main subject and I think we finally discussed everything. Let us know about your progress. Thanks and stay in touch.

Michael M.'s picture

Yes, my devloper ran the ia32 compiler (on our intel arch) and it worked for him. So, I'm satisfied. Thanks

Casey's picture

Zitat:

Sergey Kostrov schrieb:

>>...__x86_64

It is the most illogical macro in GCC-world I've ever seen. A developer who created the macro __x86_64 doesn't understand that x86 stands for a 32-bit platform and 64-part stands for a 64-bit platform. He "fused" these two parts ( abbreviations ) together in one macro by unknown reason.

Actually, x86 refers to an instruction set that spans decades worth of chips and contains instruction ranging between 16 and 512 bits (SIMD).  The  8086, 80186 and 80286 chips are 16 bit, the 80386 and 486 are 32 bit and all of them use the x86 instruction set. The _64 moniker is a natural nomenclature to refer to the 64bit extensions to the x86 family (which are backward compatible with one another).  It is also the most neutral branding because your only real other options anymore are AMD64 and intel64 (both of which are 64bit additions to the x86 instruction set).  I don't know that it was a single person who coined x86_64 and I don't know whether that person works under the GNU banner or some chip company.   

Whether or not  you take philisophical issue with the standardized macro, you at least know it exists should you ever find yourself developing on a UNIX or Linux platform powered by Intel or AMD chips and have a need for it.

Tim Prince's picture

The designation x86_64 goes back at least to the collaboration between AMD and SuSE http://www.amd.com/us/press-releases/Pages/Press_Release_751.aspx when the Athlon64 CPUs were about to be introduced. 

One would think someone could "retrieve" the original SuSE specification publication to add as a reference in the wikipedia article.  It was more than a historical reference; for example, it had useful specifications on alignments which didn't get implemented properly for several years.

Sergey Kostrov's picture

>>...The designation x86_64 goes back at least to the collaboration between AMD and
>>SuSE http://www.amd.com/us/press-releases/Pages/Press_Release_751.aspx when the Athlon64
>>CPUs were about to be introduced.

Thank you, Tim! Some statements in the article are impressive and it possibly explains origins of that mix of x86 and 64 abbreviations:

...
...AMD plans to extend the x86 instruction set to include a 64-bit mode...
...
...No other 64-bit solution has full native x86 32- and 64-bit compatibility...
...
...By extending the x86 instruction set to 64-bits, AMD's x86-64 technology...
...
...AMD's x86-64 architecture provides an exciting alternative to Intel's IA 64 architecture...
...

So, it is actually a legacy issue dated back to 1999 year ( date of Press Release is 10/5/1999 ).

Sergey Kostrov's picture

>>...AMD's x86-64 architecture provides an exciting alternative to Intel's IA 64 architecture...

In that case TBB library has a possible bug in, for example, tbb_machine.h header file:
...
#elif __x86_64__
#include "machine/linux_intel64.h"
#elif __ia64__
#include "machine/linux_ia64.h"
...

since it "maps" x86_64 to intel64 instead of ia64.

Note: There are more cases like this one, I mean incorrect "mapping", in TBB library and Intel intrinsic header files (!).

Tim Prince's picture

Zitat:

Sergey Kostrov schrieb:

#elif __x86_64__
#include "machine/linux_intel64.h"
#elif __ia64__
#include "machine/linux_ia64.h"
...

This looks OK, if still confusing.  Intel originally set em64t as their marketing version of x86_64, later deciding that Intel64 would work better.  IA64 remained associated with Itanium.  TBB could run on IA64, although Intel compiler releases for Itanium don't include it.

The soon to be announced full line of Ivy Bridge servers may have wiped out most remaining interest in Itanium.  NASA Ames retired their big Itanium cluster a few months ago, replaced by SGI UV Xeon servers, and now are replacing their remaining Harpertown by Ivy Bridge.

Sergey Kostrov's picture

This is simply to let you know that a new thread related to __x86_64 macro is created at Watercooler / Catchall Forum:

Forum Topic: Origins of __X86_64 macro used in header files of GCC and Intel compilers and TBB library
Web-link: http://software.intel.com/en-us/forums/topic/405181

Please follow the web-link provided in case of any questions related to __x86_64 macro. Thanks.

Login to leave a comment.