Tips for Porting software to a 64-bit platform

Tips for Porting software to a 64-bit platform

Imagen de Sergey Kostrov

I'd like to share some experience on porting a C/C++ project to a 64-bit platform. It was started last week and I already
have lots of different problems.

Here is a list of Tips, Detected Problems and Issues:

1. I recommend to take a look at the following topics on MSDN if you're about to start a 64-bit programming:

"Platform SDK: 64-bit Windows Programming"
"Migration Tips"
"64-Bit Programming with Visual C++"
"How to: Configure Projects to Target Platforms"

2. Turn on a /Wp64 compiler option for Microsoft compatible C++ compilers. It detects 64-bit
portability problems on types that are marked with the __w64 keyword;

3. Issue - LONGLONG data type:
...
#if !defined( _M_IX86 )
typedef __int64 LONGLONG;
#else
typedef double LONGLONG;
#endif
...

4. Issue - Date & Time CRT-functions and data types

5. Issue - A 'size_t' type is used in 'new' C++ operators to pass a size of a memory to allocate and
it is 8-bytes long on a 64-bit platform

6. Microsoft C++ compiler ( a test case ):
...
int iInt32 = 0xffffeeeeddddcccc; // -> iInt32 = 0xddddcccc - This is simplya verification of truncation
...

7. Problem - MinGW C++ compiler ( a test case ):
...
int iInt32 = 0xffffeeeeddddcccc; // -> Error: integer constant is too large for "long" type
...

8. Use explicit 'ifdef's for different platforms ( pseudo codes ):
...
#ifdef _16BIT_PLATFORM_
//...
#endif
#ifdef _32BIT_PLATFORM_
//...
#endif
#ifdef _64BIT_PLATFORM_
//...
#endif
...

9. Default ( turn on ) the following warnigs for Microsoft compatible C++ compilers:

#pragma warning ( default : 4239 )// Nonstandard extension used : 'type cast' : conversion from 'type1' to 'type2'
#pragma warning ( default : 4242 )// Conversion from 'type1' to 'type2', possible loss of data
#pragma warning ( default : 4244 )// Conversion from 'type1' to 'type2', possible loss of data
#pragma warning ( default : 4305 )// 'Initializing' : truncation from 'type1' to 'type2'
#pragma warning ( default : 4309 )// 'Initializing' : truncation of constant value
#pragma warning ( default : 4311 )// 'Type cast' : pointer truncation from 'type1' to 'type2'

10. Verify how the __w64 keyword works for Microsoft compatible C++ compilers:

// Test Case - Verification of __w64 keyword - based on MSDN example
// 'V64C' stands for 'Verify 64-bit Compatibility'

...
#if ( defined ( _WIN32_MSC ) || defined ( _WIN32_ICC ) )
#define _RTV64C__w64
#endif
#if ( defined ( _WIN32CE_MSC ) || defined ( _WIN32_BCC ) || defined ( _WIN32_MGW ) ||\\
defined ( _COS16_TCC ) )
#define _RTV64C
#endif
...

#pragma warning ( default : 4244 )// Conversion from 'type1' to 'type2', possible loss of data

#define _WIN64
//#undef _WIN64

typedef int Int_32;

#ifdef _WIN64
typedef __int64 Int_Native;
#else
typedef int _RTV64C Int_Native;
#endif

Int_32 iInt_32 = 0xffeeddcc;
Int_Native iInt_Native = 0xffffeeeeddddcccc;
iInt_32 = iInt_Native; // MSDN - Warning C4244: 64-bit int assigned to 32-bit int
// Compiler - Warning C4244: '=' : conversion from 'Int_Native' to 'Int_32', possible loss of data
#undef _WIN64

#pragma warning ( disable : 4244 )
...

11. If a project has Test Cases ALL of them must be verified on a 64-bit platform

publicaciones de 62 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Sergey Kostrov

Here are a couple of screenshots that demonstrate the truncation of a 64-bit value when
assigned to a 32-bit variable:

State 1 - Values are uninitialized

State 2 - Values initialized

State 3 - A 64-bit value was assigned to a 32-bit variable

Imagen de Sergey Kostrov
Quoting Sergey Kostrov I'd like to share some experience on porting a C/C++ project to a 64-bit platform. It was started last week and I already
have lots of different problems...

...
4. Issue - Date & Time CRT-functions and data types
...

Please take a look at a thread:

Is a "Y2K38 disaster" looming? Issues with a 'time_t' type

http://software.intel.com/en-us/forums/showthread.php?t=105868&o=a&s=lr

for more technical details.

Imagen de Sergey Kostrov

Everybody is welcomed to sharea 64-bit programming experience!

Best regards,
Sergey

Imagen de Sergey Kostrov

12.Issues with a'fseek' CRT-function detected:

For a 32-bit platform it is declared as follows:
int fseek( FILE *stream, long offset, int origin );

For a 64-bit platform it is declared as follows:
int _fseeki64( FILE *stream, __int64 offset, int origin );

A macro-wrapper is needed to make codes more portable.

Imagen de Sergey Kostrov

13. Issues with some intrinsic functions detected:

Header: 'nmmintrin.h'
...
// Calculate a number of bits set to 1
...
#if defined( _M_X64 )
extern __int64 _mm_popcnt_u64( unsigned __int64 v );
#endif
...

Header: 'smmintrin.h'
...
// Insert integer into packed integer array element
// selected by index
...
#if defined( _M_X64 )
extern __m128i _mm_insert_epi64( __m128i dst, __int64 s, const int ndx );
#endif

// Extract integer from packed integer array element
// selected by index
...
#if defined( _M_X64 )
extern __int64 _mm_extract_epi64( __m128i src, const int ndx );
#endif
...

Even if __int64 and __m128i data types could be used on a 32-bit platform these intrinsic functions are not available.

Imagen de Sergey Kostrov

14. Forced truncations of Single- or Double-precision values to integer type:

In the following example:
...
float fPI = 3.141592653589793f;

float fPIint = ( int )fPI;
...

there is nothing wrong, but ifMicrosoftor Intel C++ compilers are useda warning:

C4244: '=' : conversion from 'float' to 'int', possible loss of data

will be displayed.

Imagen de Sergey Kostrov
Quoting Sergey Kostrov 9. Default ( turn on ) the following warnigs for Microsoft compatible C++ compilers:

#pragma warning ( default : 4239 )// Nonstandard extension used : 'type cast' : conversion from 'type1' to 'type2'
#pragma warning ( default : 4242 )// Conversion from 'type1' to 'type2', possible loss of data
#pragma warning ( default : 4244 )// Conversion from 'type1' to 'type2', possible loss of data
#pragma warning ( default : 4305 )// 'Initializing' : truncation from 'type1' to 'type2'
#pragma warning ( default : 4309 )// 'Initializing' : truncation of constant value
#pragma warning ( default : 4311 )// 'Type cast' : pointer truncation from 'type1' to 'type2'

In case of Intel C++ compiler default ( turn on )a warning 2259:

#pragma warning (default : 2259 ) // Non-pointer conversion from "type1" to "type2" may lose significant bits

Imagen de Maycon Oliveira

Thank you for the information! :-)

Imagen de Sergey Kostrov

15. A version 3 of the 'MemTestApp' that could be used to test allocation of large blocks of memory is attached.

Please take a look at a post:

http://software.intel.com/en-us/forums/showpost.php?p=189214

for more technical details.

Adjuntos: 

AdjuntoTamaño
Descargar MemTestAppV3.zip6.15 KB
Imagen de Arthur Moroz

16. Integer literal constant:

__int64 test = 1<<48; The result is 0! To have correct result it should look like following __int64 test = 1LL<<48;

Imagen de Sergey Kostrov
Quoting Arthur Moroz 16. Integer literal constant:
__int64 test = 1<<48; The result is 0! To have correct result it should look like following __int64 test = 1LL<<48;

Thank you and it is a really good note. I also had a similarissue and'LL' or 'ULL' resolved it.

Imagen de Sergey Kostrov
Quoting Sergey Kostrov
Quoting Sergey Kostrov 9. Default ( turn on ) the following warnigs for Microsoft compatible C++ compilers:

#pragma warning ( default : 4239 )// Nonstandard extension used : 'type cast' : conversion from 'type1' to 'type2'
#pragma warning ( default : 4242 )// Conversion from 'type1' to 'type2', possible loss of data
#pragma warning ( default : 4244 )// Conversion from 'type1' to 'type2', possible loss of data
#pragma warning ( default : 4305 )// 'Initializing' : truncation from 'type1' to 'type2'
#pragma warning ( default : 4309 )// 'Initializing' : truncation of constant value
#pragma warning ( default : 4311 )// 'Type cast' : pointer truncation from 'type1' to 'type2'

In case of Intel C++ compiler default ( turn on )a warning 2259:

#pragma warning (default : 2259 ) // Non-pointer conversion from "type1" to "type2" may lose significant bits

A couple of notes regarding warnings. Take into account that as soon as these warnings are 'default'ed
( turned on ) you could be overwhelmed by a number of warnings during compilation of source codes.

Here is example:

- A software development environment has one Visual Studio solution and a number of different
C/C++ projects is 36. Since every project is configured for different platforms a total number of
projects to be compiled is 130

- All warnings related to 64-bit conversions are 'default'ed

- In case of rebuilding all projects a total number of warning messages is 1484

- A summary from a Visual Studio Output Window is as follows:

  ----- Build started: Project: , Configuration: Release  ------

  ...

   - 0 error(s),   2 warning(s)

   - 0 error(s), 160 warning(s)

   - 0 error(s),   1 warning(s)

   - 0 error(s),   2 warning(s)

   - 0 error(s),   1 warning(s)

   - 0 error(s),   2 warning(s)

   - 0 error(s),  83 warning(s)

   - 0 error(s), 380 warning(s)

   - 0 error(s),  97 warning(s)

   - 0 error(s), 160 warning(s)

   - 0 error(s),  99 warning(s)

   - 0 error(s),  61 warning(s)

   - 0 error(s),   2 warning(s)

   - 0 error(s), 260 warning(s)

   - 0 error(s),   4 warning(s)

   - 0 error(s),   3 warning(s)

   - 0 error(s), 167 warning(s)

  ...

  ===== Build: 130 succeeded, 0 failed, 2 up-to-date, 0 skipped ==========

Imagen de Sergey Kostrov
Quoting Sergey Kostrov 7. Problem - MinGW C++ compiler ( a test case ):
...
int iInt32 = 0xffffeeeeddddcccc; // -> Error: integer constant is too large for "long" type
...

There isa workaround and avalue 18446725308424768716( with LL or ULL )has to be used instead of 0xffffeeeeddddcccc.

Imagen de Sergey Kostrov

17. Issues - When porting a 32-bit project with IDL ( Interface Definition Language ) files for MIDL compiler.

MIDL - Microsoft Interface Definition Language

Imagen de Sergey Kostrov
Quoting Sergey Kostrov 15. A version 3 of the 'MemTestApp' that could be used to test allocation of large blocks of memory is attached.

Please take a look at a post:

http://software.intel.com/en-us/forums/showpost.php?p=189214

for more technical details.

Test Results:

OS : Windows 7 64-bit Home Premium
CPU: AMD ( 4 cores )
RAM: 6GB
VM: 96GB initial size \ 128GB maximum size
APP: MemTestApp64.exe \ Release configuration

Attempts to allocate memory:

0.25GB - Allocated
0.50GB - Allocated
1.GB - Allocated
2.GB - Allocated
4.GB - Allocated
8.GB - Allocated
14.GB - Allocated ( Target for a 61000x61000 Single-Precision matrix )
16.GB - Allocated
28.GB - Allocated ( Target for a 61000x61000 Double-Precision matrix )
32.GB - Allocated
64.GB - Allocated

Imagen de Sergey Kostrov
Quoting Sergey Kostrov ...
2. Turn on a /Wp64 compiler option for Microsoft compatible C++ compilers. It detects 64-bit
portability problems on types that are marked with the __w64 keyword;
...

This is simply to note that 'Wp64' compiler option is deprecatedand Visual Studio 2008 ( Professional & Express Editions)displays
awarning message:
...
cl : Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release
...

Imagen de Sergey Kostrov

18. Intel 64-bit Mode Coding Guidelines

Intel 64 and IA-32 Architectures Optimization Reference Manual
November 2007

Chapter 9. 64-bit Mode Coding Guidelines

Note: 5 pages only

Imagen de Sergey Kostrov

19. Regarding /LARGEADDRESSAWARE linker option:
.
This is what MSDN says:
...
The /LARGEADDRESSAWARE option tells the linker that an application supports addresses larger than 2 gigabytes.
...
However, it doesn't mean that a 32-bit application that was built with enabled /LARGEADDRESSAWARE linker option could allocate greater than 2GB of memory. It is simply not possible on a 32-bit Windows platform without AWE and on 64-bit Windows platforms.
.
AWE - Address Windowing Extensions

Imagen de Tim Prince

Ability to allocate beyond the 2GB barrier in 32-bit Windows was introduced with the XP /3GB boot switch. The space is fragmented. After the 2GB is used up, additional non-contiguous allocations within the additional 1GB space are supported, with the additional linker switch.
If it were not for mobile devices, one would think 32-bit Windows obsolete.

Imagen de Sergey Kostrov

I would like to mention that AWE is only supported on some Windows operating systems, like Server or Enterprise Editions, and it is NOT supported on Home Editions.
.
>>...one would think 32-bit Windows obsolete...
.
There are still too many users with 32-bit Windows. So, it will be used for many years.

Imagen de Sergey Kostrov

This is a test post with embedded jpg-format image.
.
C:\intel_logo.jpg

Imagen de Sergey Kostrov

>>...This is a test post with embedded jpg-format image.
.
It didn't work if an image is located on a local drive. I expected that it would be uploaded automatically. Here is my question: How could I embedd an image in a post? Thanks in advance.

Imagen de Sergey Kostrov

This is a test post - investigation of performance issues on the new IDZ website ( done from a dual-core computer ).

Imagen de Sergey Kostrov

>>http://software.intel.com/en-us/forums/showpost.php?p=189214
>>
>>for more technical details.
>>
>>Test Results:
>>
>>OS : Windows 7 64-bit Home Premium
>>CPU: AMD ( 4 cores )
>>RAM: 6GB
>>VM: 96GB initial size \ 128GB maximum size
>>APP: MemTestApp64.exe \ Release configuration
>>
>>Attempts to allocate memory:
>>
>>0.25GB - Allocated
>>0.50GB - Allocated
>>1.GB - Allocated
>>2.GB - Allocated
>>4.GB - Allocated
>>8.GB - Allocated
>>14.GB - Allocated ( Target for a 61000x61000 Single-Precision matrix )
>>16.GB - Allocated
>>28.GB - Allocated ( Target for a 61000x61000 Double-Precision matrix )
>>32.GB - Allocated
>>64.GB - Allocated

Just verified how MemTestApp64.exe works on a system with Windows 7 Professional and Intel CPU ( 16GB of physical memory / VM: 96GB initial size \ 128GB maximum size ):

0.25GB - Allocated
0.50GB - Allocated
1.GB - Allocated
2.GB - Allocated
4.GB - Allocated
8.GB - Allocated
14.GB - Allocated ( Target for a 61000x61000 Single-Precision matrix )
16.GB - Allocated
28.GB - Allocated ( Target for a 61000x61000 Double-Precision matrix )
32.GB - Allocated
64.GB - Allocated

A screenshot will be provided for cases 4GB, 8GB, 16GB, 32GB and 64GB.

Adjuntos: 

AdjuntoTamaño
Descargar memtestapp64.jpg109.69 KB
Imagen de Sergey Kostrov

Here is a screenshot of the Windows Resource Monitor for cases 4GB, 8GB, 16GB, 32GB and 64GB:

Imagen de Sergey Kostrov

>>...Here is a screenshot of the Windows Resource Monitor for cases 4GB, 8GB, 16GB, 32GB and 64GB...

It took more than 5 attempts before the image was finally embedded.

Imagen de Sergey Kostrov

20. A version 4 of the 'MemTestApp' that could be used to test allocation of large blocks of memory is attached. I tested the application for a couple of extreme cases ( from 64GB up to 192GB ).

Adjuntos: 

AdjuntoTamaño
Descargar memtestappv4.zip6.64 KB
Imagen de Sergey Kostrov

Here is a screenshot of the Windows Resource Monitor for cases 16GB, 32GB, 64GB, 128GB, 160GB and 192GB:

Adjuntos: 

AdjuntoTamaño
Descargar memtestapp64.jpg120.39 KB
Imagen de Sergey Kostrov

21. Here are a couple of notes related to allocation of memory on the stack ( also known as automatic allocation ):

- For 'float' Floating-Point data type maximum size of the matrix in case of automatic allocation on the stack is ~23170x23170

- For 'double' Floating-Point data type maximum size of the matrix in case of automatic allocation on the stack is ~16383x16383

- In cases when it exceeds the 2GB limit a C/C++ compiler or a Fortran compiler could fail to compile sources. For example, MS C++ compiler fails with an Error C1126: automatic allocation exceeds 2G

- In cases when it exceeds the 2GB limit a C/C++ compiler or a Fortran compiler could fail to compile sources. For example, MS C++ compiler fails with an Error C2148: total size of array must not exceed 0x7FFFFFFF bytes

0x7FFFFFFF = 2147483647 bytes

Imagen de Sergey Kostrov

22. Take into account that all editions of Visual Studio Express ( 2008, 2010, 2012, etc ) don't support development for 64-bit platforms.

Imagen de Sergey Kostrov

>>22. Take into account that all editions of Visual Studio Express ( 2008, 2010, 2012, etc ) don't support development for 64-bit platforms.

Correction. Visual Studio Express 2012 for WIndows 8 and for Windows Desktop allow to create applications for 64-bit platforms. Take a look at 'Supported architectures' sections at:

Web-link: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express...
and
Web-link: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express...

Imagen de iliyapolak

>>>Correction. Visual Studio Express 2012 for WIndows 8 and for Windows Desktop allow to create applications for 64-bit platforms. Take a look at 'Supported architectures' sections at:>>>

Thanks for posting this.

Imagen de iliyapolak

I would like to add that Microsoft did a good job of integrating and combining driver development with Visual Studio IDE environment.

Imagen de Sergey Kostrov

>>...Microsoft did a good job of integrating and combining driver development with Visual Studio IDE...

Please take into account that the subject of the thread is Tips for Porting software to a 64-bit platform and it is not related to porting drivers to a 64-bit Windows platform(s).

Imagen de iliyapolak

Quote:

Sergey Kostrov wrote:

>>...Microsoft did a good job of integrating and combining driver development with Visual Studio IDE...

Please take into account that the subject of the thread is Tips for Porting software to a 64-bit platform and it is not related to porting drivers to a 64-bit Windows platform(s).

Ok:)

@Sergey
Do you do any kind of driver development?

Imagen de Sergey Kostrov

>>@Sergey
>>Do you do any kind of driver development?

Long time ago I've implemented two simple drivers for Windows 95 OS but, unfortunately, I'm not interested in the driver programming any longer.

Imagen de Sergey Kostrov

23. Two problems with MinGW C/C++ compiler detected:

[ Problem 1 ]

...
__int64 iValueS = 0LL;

iValueS = ( 9223372036854775807i64 );
...

Compilation error Invalid suffix 'i64' on integer constant with MinGW C/C++ compiler.

Use LL instead of i64.

[ Problem 2 ]

Compilation error Integer constant is too large for 'long' type if assignment to a signed 64-bit variable with a max value is done without using LL suffix:

...
__int64 iValueS = ( 9223372036854775807 );
...

MinGW C/C++ compiler casts to a type 'long' instead of to a type 'long long'.

Imagen de Sergey Kostrov

24. A problem with Borland C/C++ compiler detected:

[ Problem ]

Take into account that Borland C++ compiler, for example version 5.x, doesn't support suffixes LL and ULL.

Imagen de iliyapolak

>>>Two problems with MinGW C/C++ compiler detected:>>>

Have you tested with MinGW compiler usage of suffixes such like a UL and LL in macro definition?

Imagen de iliyapolak

>>>Long time ago I've implemented two simple drivers for Windows 95 OS but, unfortunately, I'm not interested in the driver programming any longer.>>>

I thought that you could have been able to help me with my project.So far nobody was able to help me.
here is link:http://software.intel.com/en-us/forums/topic/351986

Imagen de Sergey Kostrov

25. Floating Point Unit precision control on a 64-bit platform:

Take into account that on 64-bit platforms changing the floating-point precision is not supported. If the precision control mask _MCW_PC is used on a 64-bit platform a Debug Assertion Failed message will be displayed.

When, for example, a _control87 CRT-function is called in an application ( Debug configuration only! ) the following expression is verified:

...( mask &~ ( _MCW_DN | _MCW_EM | _MCW_RC ) ) == 0...

and it checks if there is an attempt to change precision, or in another words there is attempt to set _MCW_PC bits.

In a Release configuration there are No any errors or warning messages.

Imagen de Sergey Kostrov

>>...If the precision control mask _MCW_PC is used on a 64-bit platform a Debug Assertion Failed message will be displayed...

This is how it looks like:



The message comes from msvcr80d.dll.

You can press Ignore button because the message is actually a warning.

Imagen de Sergey Kostrov

26. CRT-function _set_SSE2_enable is Not supported for 64-bit Windows platforms ( see declaration ):

[ math.h ]
...
#if defined( _M_IX86 )
...
_CRTIMP int __cdecl _set_SSE2_enable(__in int _Flag);
...
#endif
...

Imagen de Sergey Kostrov

27. Declaration of Naked functions with _declspec( naked ) is Not supported on 64-bit Windows platforms ( it is Not clear if a similar feature exists in C++ compilers for Linux platforms ). This is an example of a compilation error of Microsoft C++ compiler:
...
SomeHeader.h(83) : error C2485: 'naked' : unrecognized extended attribute
...

Imagen de Sergey Kostrov

28. Inline assembler ( keywords _asm or __asm ) is Not supported in C/C++ source files on 64-bit Windows platforms. This is an example of a compilation error of Microsoft C++ compiler:
...
SomeHeader.h(98) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture
...

[ A quote from MSDN ]
...
Inline assembler is not supported on the Itanium and x64 processors.
...
Programs with inline assembler code are not fully portable to other hardware platforms. If you are designing for portability, avoid using inline assembler.
...

Imagen de Sergey Kostrov

29. Take into account that with Microsoft compatible C++ compilers _M_X64 and _M_AMD64 macros are defined (!):
...
// INTEL _M_X64 ( 64-bit )
// AMD _M_AMD64 ( 64-bit )
...

[ Example from a Visual Studio Output Window ]

------ Build All started: Project: GenTestApp, Configuration: Debug x64 ------
Compiling...
Stdphf.cpp
...
*** Message: Compiling with Visual Studio 2005 ***
*** Message: Configuration - Desktop - _WIN32_MSC - DEBUG ***
...
*** Message: Compiling for Intel Processing Unit ( 64-bit ) ***
*** Message: Compiling for AMD Processing Unit ( 64-bit ) ***
...
Compiling...
GenTestApp.cpp
Compiling manifest to resources...
Linking...
Creating library x64\Debug/GenTestAppD.lib and object x64\Debug/GenTestAppD.exp
GenTestApp - 0 error(s), 0 warning(s)

Imagen de iliyapolak

>>>... Programs with inline assembler code are not fully portable to other hardware platforms. If you are designing for portability, avoid using inline assembler>>>

There is also no compiler optimization performed inside _asm block.This is related to x86 architecture.

Imagen de Sergey Kostrov

>>...There is also no compiler optimization performed inside _asm block.This is related to x86 architecture.

The thread is related to porting 32-bit ( x86 ) codes on 64-bit ( x64 ) platforms only.

Imagen de Sergey Kostrov

>>...2. Turn on a /Wp64 compiler option for Microsoft compatible C++ compilers. It detects 64-bit
>>portability problems on types that are marked with the __w64 keyword;

Visual Studio 2008 gives a warning that '...option 'Wp64' has been deprecated and will be removed in a future release...' of a Visual Studio.

Here is additional information:

Visual Studio 2003 - 'Wp64' possibly supported ( very obsolete version )
Visual Studio 2005 - 'Wp64' supported ( still in use )
Visual Studio 2008 - 'Wp64' supported ( warning is given )
Visual Studio 2010 - 'Wp64' should not be supported ( I didn't verify it )
Visual Studio 2012 - 'Wp64' should not be supported ( I didn't verify it )

Imagen de Sergey Kostrov

Update...

>>...
>>SomeHeader.h(98) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture
>>...
>>
>>[ A quote from MSDN ]
>>...
>>Inline assembler is not supported on the Itanium and x64 processors.
>>...
>>Programs with inline assembler code are not fully portable to other hardware platforms. If you are designing for portability,
>>avoid using inline assembler.
>>...

Intel C++ compiler supports (!) inline assembler in C/C++ codes targeted for 64-bit Windows platforms!

Páginas

Inicie sesión para dejar un comentario.