You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/assembler/masm/processor-manufacturer-programming-manuals.md
+16-16Lines changed: 16 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -1,25 +1,25 @@
1
-
---
2
-
title: "Processor Manufacturer Programming Manuals | Microsoft Docs"
3
-
ms.custom: ""
4
-
ms.date: "11/04/2016"
5
-
ms.technology: ["cpp-masm"]
6
-
ms.topic: "reference"
7
-
dev_langs: ["C++"]
8
-
ms.assetid: 61844163-de2f-419a-808e-04de39dfdddf
9
-
author: "corob-msft"
10
-
ms.author: "corob"
11
-
ms.workload: ["cplusplus"]
1
+
---
2
+
title: "Processor Manufacturer Programming Manuals | Microsoft Docs"
3
+
ms.custom: ""
4
+
ms.date: "11/04/2016"
5
+
ms.technology: ["cpp-masm"]
6
+
ms.topic: "reference"
7
+
dev_langs: ["C++"]
8
+
ms.assetid: 61844163-de2f-419a-808e-04de39dfdddf
9
+
author: "corob-msft"
10
+
ms.author: "corob"
11
+
ms.workload: ["cplusplus"]
12
12
---
13
13
# Processor Manufacturer Programming Manuals
14
14
This article provides links to websites that may contain programming information about processors that are not manufactured, sold, or supported by Microsoft. Microsoft does not own or control the websites or the content on them.
15
15
16
16
## Processor Manufacturer Websites
17
17
18
-
-[AMD64 Instruction Set Reference Manuals](http://go.microsoft.com/fwlink/p/?LinkID=219796)
19
-
20
-
-[Intel 64 and IA-32 Architectures Software Developer Manuals](http://go.microsoft.com/fwlink/p/?LinkID=219798)
Note the following restrictions on the use of **/clr**:
16
-
17
-
- In a structured exception handler, there are restrictions on using `_alloca` when compiling with **/clr**. For more information, see [_alloca](../../c-runtime-library/reference/alloca.md).
18
-
19
-
- The use of run-time error checks is not valid with **/clr**. For more information, see [How to: Use Native Run-Time Checks](/visualstudio/debugger/how-to-use-native-run-time-checks).
20
-
21
-
- When **/clr** is used to compile a program that only uses standard C++ syntax, the following guidelines apply to the use of inline assembly:
22
-
23
-
- Inline assembly code that assumes knowledge of the native stack layout, calling conventions outside of the current function, or other low-level information about the computer may fail if that knowledge is applied to the stack frame for a managed function. Functions containing inline assembly code are generated as unmanaged functions, as if they were placed in a separate module that was compiled without **/clr**.
24
-
25
-
- Inline assembly code in functions that pass copy-constructed function parameters is not supported.
26
-
27
-
- The [vprintf Functions](../../c-runtime-library/vprintf-functions.md) cannot be called from a program compiled with **/clr**.
28
-
29
-
- The [naked](../../cpp/naked-cpp.md)[__declspec](../../cpp/declspec.md) modifier is ignored under /clr.
30
-
31
-
- The translator function set by [_set_se_translator](../../c-runtime-library/reference/set-se-translator.md) will affect only catches in unmanaged code. See [Exception Handling](../../windows/exception-handling-cpp-component-extensions.md) for more information.
32
-
33
-
- The comparison of function pointers is not permitted under **/clr**.
34
-
35
-
- The use of functions that are not fully prototyped is not permitted under **/clr**.
36
-
37
-
- The following compiler options are not supported with **/clr**:
38
-
39
-
-**/EHsc** and **/EHs** (**/clr** implies **/EHa** (see [/EH (Exception Handling Model)](../../build/reference/eh-exception-handling-model.md))
40
-
41
-
-**/fp:strict** and **/fp:except** (see [/fp (Specify Floating-Point Behavior)](../../build/reference/fp-specify-floating-point-behavior.md))
- The combination of the `_STATIC_CPPLIB` preprocessor definition (`/D_STATIC_CPPLIB`) and the **/clr** compiler option is not supported. This is so because the definition would cause your application to link with the static multithreaded C++ Standard Library, which is not supported. For more information, see the [/MD, /MT, /LD (Use Run-Time Library)](../../build/reference/md-mt-ld-use-run-time-library.md) topic.
54
-
55
-
- When using **/Zi** with **/clr**, there are performance implications. For more information, see [/Zi](../../build/reference/z7-zi-zi-debug-information-format.md).
56
-
57
-
- Passing a wide character to a .NET Framework output routine without also specifying [/Zc:wchar_t](../../build/reference/zc-wchar-t-wchar-t-is-native-type.md) or without casting the character to `__wchar_t` will cause the output to appear as an `unsigned short int`. For example:
58
-
59
-
```
60
-
Console::WriteLine(L' ') // Will output 32.
61
-
Console::WriteLine((__wchar_t)L' ') // Will output a space.
62
-
```
63
-
64
-
- [/GS](../../build/reference/gs-buffer-security-check.md) is ignored when compiling with **/clr**, unless a function is under `#pragma` [unmanaged](../../preprocessor/managed-unmanaged.md) or if the function must be compiled to native, in which case the compiler will generate warning C4793, which is off by default.
65
-
66
-
- See [/ENTRY](../../build/reference/entry-entry-point-symbol.md) for function signature requirements of a managed application.
67
-
68
-
- Applications compiled with **/openmp** and **/clr** can only be run in a single appdomain process. See [/openmp (Enable OpenMP 2.0 Support)](../../build/reference/openmp-enable-openmp-2-0-support.md) for more information.
69
-
70
-
- Functions that take a variable number of arguments (varargs) will be generated as native functions. Any managed data types in the variable argument position will be marshaled to native types. Note that <xref:System.String?displayProperty=fullName> types are actually wide-character strings, but they are marshaled to single-byte character strings. So if a printf specifier is %S (wchar_t*), it will marshal to a %s string instead.
71
-
72
-
- When using the va_arg macro, you may get unexpected results when compiling with **/clr:pure**. For more information, see [va_arg, va_copy, va_end, va_start](../../c-runtime-library/reference/va-arg-va-copy-va-end-va-start.md).
73
-
74
-
- You should not call, from managed code, any functions that walk the stack to get parameter information (function arguments); the P/Invoke layer causes that information to be further down the stack. For example, do not compile proxy/stub with **/clr**.
75
-
76
-
- Functions will be compiled to managed code whenever possible, but not all C++ constructs can be translated to managed code. This determination is made on a function-by-function basis. If any part of a function cannot be converted to managed code, the entire function will be converted to native code instead. The following cases prevent the compiler from generating managed code.
77
-
78
-
- Compiler-generated thunks or helper functions. Native thunks are generated for any function call through a function pointer, including virtual function calls.
79
-
80
-
- Functions that call `setjmp` or `longjmp`.
81
-
82
-
- Functions that use certain intrinsic routines to directly manipulate machine resources. For example, the use of `__enable` and `__disable`, `_ReturnAddress` and `_AddressOfReturnAddress`, or multimedia intrinsics will all result in native code.
83
-
84
-
- Functions that follow the `#pragma unmanaged` directive. (Note that the inverse, `#pragma managed`, is also supported.)
85
-
86
-
- A function that contains references to aligned types, that is, types declared using `__declspec(align(...))`.
87
-
88
-
## See Also
89
-
[/clr (Common Language Runtime Compilation)](../../build/reference/clr-common-language-runtime-compilation.md)
15
+
16
+
Note the following restrictions on the use of **/clr**:
17
+
18
+
- In a structured exception handler, there are restrictions on using `_alloca` when compiling with **/clr**. For more information, see [_alloca](../../c-runtime-library/reference/alloca.md).
19
+
20
+
- The use of run-time error checks is not valid with **/clr**. For more information, see [How to: Use Native Run-Time Checks](/visualstudio/debugger/how-to-use-native-run-time-checks).
21
+
22
+
- When **/clr** is used to compile a program that only uses standard C++ syntax, the following guidelines apply to the use of inline assembly:
23
+
24
+
- Inline assembly code that assumes knowledge of the native stack layout, calling conventions outside of the current function, or other low-level information about the computer may fail if that knowledge is applied to the stack frame for a managed function. Functions containing inline assembly code are generated as unmanaged functions, as if they were placed in a separate module that was compiled without **/clr**.
25
+
26
+
- Inline assembly code in functions that pass copy-constructed function parameters is not supported.
27
+
28
+
- The [vprintf Functions](../../c-runtime-library/vprintf-functions.md) cannot be called from a program compiled with **/clr**.
29
+
30
+
- The [naked](../../cpp/naked-cpp.md)[__declspec](../../cpp/declspec.md) modifier is ignored under /clr.
31
+
32
+
- The translator function set by [_set_se_translator](../../c-runtime-library/reference/set-se-translator.md) will affect only catches in unmanaged code. See [Exception Handling](../../windows/exception-handling-cpp-component-extensions.md) for more information.
33
+
34
+
- The comparison of function pointers is not permitted under **/clr**.
35
+
36
+
- The use of functions that are not fully prototyped is not permitted under **/clr**.
37
+
38
+
- The following compiler options are not supported with **/clr**:
39
+
40
+
-**/EHsc** and **/EHs** (**/clr** implies **/EHa** (see [/EH (Exception Handling Model)](../../build/reference/eh-exception-handling-model.md))
41
+
42
+
-**/fp:strict** and **/fp:except** (see [/fp (Specify Floating-Point Behavior)](../../build/reference/fp-specify-floating-point-behavior.md))
- The combination of the `_STATIC_CPPLIB` preprocessor definition (`/D_STATIC_CPPLIB`) and the **/clr** compiler option is not supported. This is so because the definition would cause your application to link with the static multithreaded C++ Standard Library, which is not supported. For more information, see the [/MD, /MT, /LD (Use Run-Time Library)](../../build/reference/md-mt-ld-use-run-time-library.md) topic.
55
+
56
+
- When using **/Zi** with **/clr**, there are performance implications. For more information, see [/Zi](../../build/reference/z7-zi-zi-debug-information-format.md).
57
+
58
+
- Passing a wide character to a .NET Framework output routine without also specifying [/Zc:wchar_t](../../build/reference/zc-wchar-t-wchar-t-is-native-type.md) or without casting the character to `__wchar_t` will cause the output to appear as an `unsigned short int`. For example:
59
+
60
+
```cpp
61
+
Console::WriteLine(L' ') // Will output 32.
62
+
Console::WriteLine((__wchar_t)L' ') // Will output a space.
63
+
```
64
+
65
+
-[/GS](../../build/reference/gs-buffer-security-check.md) is ignored when compiling with **/clr**, unless a function is under `#pragma`[unmanaged](../../preprocessor/managed-unmanaged.md) or if the function must be compiled to native, in which case the compiler will generate warning C4793, which is off by default.
66
+
67
+
- See [/ENTRY](../../build/reference/entry-entry-point-symbol.md) for function signature requirements of a managed application.
68
+
69
+
- Applications compiled with **/openmp** and **/clr** can only be run in a single appdomain process. See [/openmp (Enable OpenMP 2.0 Support)](../../build/reference/openmp-enable-openmp-2-0-support.md) for more information.
70
+
71
+
- Functions that take a variable number of arguments (varargs) will be generated as native functions. Any managed data types in the variable argument position will be marshaled to native types. Note that <xref:System.String?displayProperty=fullName> types are actually wide-character strings, but they are marshaled to single-byte character strings. So if a printf specifier is %S (wchar_t*), it will marshal to a %s string instead.
72
+
73
+
- When using the va_arg macro, you may get unexpected results when compiling with **/clr:pure**. For more information, see [va_arg, va_copy, va_end, va_start](../../c-runtime-library/reference/va-arg-va-copy-va-end-va-start.md). The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017. Code that must be "pure" or "safe" should be ported to C#.
74
+
75
+
- You should not call, from managed code, any functions that walk the stack to get parameter information (function arguments); the P/Invoke layer causes that information to be further down the stack. For example, do not compile proxy/stub with **/clr**.
76
+
77
+
- Functions will be compiled to managed code whenever possible, but not all C++ constructs can be translated to managed code. This determination is made on a function-by-function basis. If any part of a function cannot be converted to managed code, the entire function will be converted to native code instead. The following cases prevent the compiler from generating managed code.
78
+
79
+
- Compiler-generated thunks or helper functions. Native thunks are generated for any function call through a function pointer, including virtual function calls.
80
+
81
+
- Functions that call `setjmp` or `longjmp`.
82
+
83
+
- Functions that use certain intrinsic routines to directly manipulate machine resources. For example, the use of `__enable` and `__disable`, `_ReturnAddress` and `_AddressOfReturnAddress`, or multimedia intrinsics will all result in native code.
84
+
85
+
- Functions that follow the `#pragma unmanaged` directive. (Note that the inverse, `#pragma managed`, is also supported.)
86
+
87
+
- A function that contains references to aligned types, that is, types declared using `__declspec(align(...))`.
88
+
89
+
## See also
90
+
91
+
-[/clr (Common Language Runtime Compilation)](../../build/reference/clr-common-language-runtime-compilation.md)
Copy file name to clipboardExpand all lines: docs/build/reference/clrheader.md
+30-25Lines changed: 30 additions & 25 deletions
Original file line number
Diff line number
Diff line change
@@ -13,28 +13,33 @@ ms.author: "corob"
13
13
ms.workload: ["cplusplus"]
14
14
---
15
15
# /CLRHEADER
16
-
```
17
-
/CLRHEADER file
18
-
```
19
-
20
-
## Remarks
21
-
where:
22
-
23
-
`file`
24
-
An image file built with [/clr](../../build/reference/clr-common-language-runtime-compilation.md).
25
-
26
-
## Remarks
27
-
CLRHEADER displays information about the .NET headers used in any managed program. The output shows the location and size, in bytes, of the .NET header and sections in the header.
28
-
29
-
Only the [/HEADERS](../../build/reference/headers.md) DUMPBIN option is available for use on files produced with the [/GL](../../build/reference/gl-whole-program-optimization.md) compiler option.
30
-
31
-
When /CLRHEADER is used on a file that was compiled with /clr, there will be a **clr Header:** section in the dumpbin output. The value of **flags** indicates which /clr option was used:
32
-
33
-
- 0 -- /clr (image may contain native code).
34
-
35
-
You can also programmatically check if an image was built for the common language runtime. For more information, see [How to: Determine if an Image is Native or CLR](../../dotnet/how-to-determine-if-an-image-is-native-or-clr.md).
36
-
37
-
The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and will be removed in a future version of the compiler. Code that must be "pure" or "safe" should be ported to C#.
*file*| An image file built with [/clr](../../build/reference/clr-common-language-runtime-compilation.md).
28
+
29
+
## Remarks
30
+
31
+
**/CLRHEADER** displays information about the .NET headers used in any managed program. The output shows the location and size, in bytes, of the .NET header and sections in the header.
32
+
33
+
Only the [/HEADERS](../../build/reference/headers.md) DUMPBIN option is available for use on files produced with the [/GL](../../build/reference/gl-whole-program-optimization.md) compiler option.
34
+
35
+
When **/CLRHEADER** is used on a file that was compiled with /clr, there will be a **clr Header:** section in the dumpbin output. The value of **flags** indicates which /clr option was used:
36
+
37
+
- 0 -- /clr (image may contain native code).
38
+
39
+
You can also programmatically check if an image was built for the common language runtime. For more information, see [How to: Determine if an Image is Native or CLR](../../dotnet/how-to-determine-if-an-image-is-native-or-clr.md).
40
+
41
+
The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017. Code that must be "pure" or "safe" should be ported to C#.
0 commit comments