drginfo/ia32-64
1
0
Fork 0
forked from NRZCode/ia32-64
Code Pull requests Activity
ia32-64/x86/xsavec.html
NRZ Code 92622c37d6 Initial commit
2025-07-08 02:23:29 -03:00

185 lines
11 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg" xmlns:x86="http://www.felixcloutier.com/x86"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><link rel="stylesheet" type="text/css" href="style.css"></link><title>XSAVEC
— Save Processor Extended States With Compaction</title></head><body><header><nav><ul><li><a href='index.html'>Index</a></li><li>December 2023</li></ul></nav></header><h1>XSAVEC
— Save Processor Extended States With Compaction</h1>
<table>
<tr>
<th>Opcode / Instruction</th>
<th>Op/En</th>
<th>64/32 bit Mode Support</th>
<th>CPUID Feature Flag</th>
<th>Description</th></tr>
<tr>
<td>NP 0F C7 /4 XSAVEC mem</td>
<td>M</td>
<td>V/V</td>
<td>XSAVEC</td>
<td>Save state components specified by EDX:EAX to mem with compaction.</td></tr>
<tr>
<td>NP REX.W + 0F C7 /4 XSAVEC64 mem</td>
<td>M</td>
<td>V/N.E.</td>
<td>XSAVEC</td>
<td>Save state components specified by EDX:EAX to mem with compaction.</td></tr></table>
<h2 id="instruction-operand-encoding">Instruction Operand Encoding<a class="anchor" href="#instruction-operand-encoding">
</a></h2>
<table>
<tr>
<th>Op/En</th>
<th>Operand 1</th>
<th>Operand 2</th>
<th>Operand 3</th>
<th>Operand 4</th></tr>
<tr>
<td>M</td>
<td>ModRM:r/m (w)</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td></tr></table>
<h2 id="description">Description<a class="anchor" href="#description">
</a></h2>
<p>Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.</p>
<p>The format of the XSAVE area is detailed in Section 13.4, “XSAVE Area,” of Intel<sup>®</sup> 64 and IA-32 Architectures Software Developer’s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, “x87 State” of Intel<sup>®</sup> 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.</p>
<p>Section 13.10, “Operation of XSAVEC,” of Intel<sup>®</sup> 64 and IA-32 Architectures Software Developer’s Manual, Volume 1 provides a detailed description of the operation of the XSAVEC instruction. The following items provide a highlevel outline:</p>
<ul>
<li>Execution of XSAVEC is similar to that of XSAVE. XSAVEC differs from XSAVE in that it uses compaction and that it may use the init optimization.</li>
<li>XSAVEC saves state component <em>i </em>if and only if RFBM[<em>i</em>] = 1 and XINUSE[<em>i</em>] = 1.<sup>1 </sup>(XINUSE is a bitmap by which the processor tracks the status of various state components. See Section 13.6, “Processor Tracking of XSAVEManaged State” of Intel<sup>® </sup>64 and IA-32 Architectures Software Developer’s Manual, Volume 1.)</li>
<li>XSAVEC does not modify bytes 511:464 of the legacy region of the XSAVE area (see Section 13.4.1, “Legacy Region of an XSAVE Area” of Intel<sup>® </sup>64 and IA-32 Architectures Software Developer’s Manual, Volume 1).</li>
<li>XSAVEC writes the logical AND of RFBM and XINUSE to the XSTATE_BV field of the XSAVE header.<sup>2,3 </sup>(See Section 13.4.2, “XSAVE Header” of Intel<sup>® </sup>64 and IA-32 Architectures Software Developer’s Manual, Volume 1.) XSAVEC sets bit 63 of the XCOMP_BV field and sets bits 62:0 of that field to RFBM[62:0]. XSAVEC does not write to any parts of the XSAVE header other than the XSTATE_BV and XCOMP_BV fields.</li>
<li>XSAVEC always uses the compacted format of the extended region of the XSAVE area (see Section 13.4.3, “Extended Region of an XSAVE Area” of Intel<sup>® </sup>64 and IA-32 Architectures Software Developer’s Manual, Volume 1).</li></ul>
<blockquote>
<p>1. There is an exception for state component 1 (SSE). MXCSR is part of SSE state, but XINUSE[1] may be 0 even if MXCSR does not have its initial value of 1F80H. In this case, XSAVEC saves SSE state as long as RFBM[1] = 1.</p>
<p>2. Unlike XSAVE and XSAVEOPT, XSAVEC clears bits in the XSTATE_BV field that correspond to bits that are clear in RFBM.</p>
<p>3. There is an exception for state component 1 (SSE). MXCSR is part of SSE state, but XINUSE[1] may be 0 even if MXCSR does not have its initial value of 1F80H. In this case, XSAVEC sets XSTATE_BV[1] to 1 as long as RFBM[1] = 1.</p></blockquote>
<p>Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.</p>
<h2 id="operation">Operation<a class="anchor" href="#operation">
</a></h2>
<pre>RFBM := XCR0 AND EDX:EAX;
/* bitwise logical AND */
TO_BE_SAVED := RFBM AND XINUSE;
/* bitwise logical AND */
If MXCSR ≠ 1F80H AND RFBM[1]
TO_BE_SAVED[1] = 1;
FI;
IF TO_BE_SAVED[0] = 1
THEN store x87 state into legacy region of XSAVE area;
FI;
IF TO_BE_SAVED[1] = 1
THEN store SSE state into legacy region of XSAVE area; // this step saves the XMM registers, MXCSR, and MXCSR_MASK
FI;
NEXT_FEATURE_OFFSET = 576;
// Legacy area and XSAVE header consume 576 bytes
FOR i := 2 TO 62
IF RFBM[i] = 1
THEN
IF TO_BE_SAVED[i]
THEN save XSAVE state component i at offset NEXT_FEATURE_OFFSET from base of XSAVE area;
FI;
NEXT_FEATURE_OFFSET = NEXT_FEATURE_OFFSET + n (n enumerated by CPUID(EAX=0DH,ECX=i):EAX);
FI;
ENDFOR;
XSTATE_BV field in XSAVE header := TO_BE_SAVED;
XCOMP_BV field in XSAVE header := RFBM OR 80000000_00000000H;
</pre>
<h2 id="flags-affected">Flags Affected<a class="anchor" href="#flags-affected">
</a></h2>
<p>None.</p>
<h2 id="intel-c-c++-compiler-intrinsic-equivalent">Intel C/C++ Compiler Intrinsic Equivalent<a class="anchor" href="#intel-c-c++-compiler-intrinsic-equivalent">
</a></h2>
<pre>XSAVEC void _xsavec( void * , unsigned __int64);
</pre>
<pre>XSAVEC64 void _xsavec64( void * , unsigned __int64);
</pre>
<h2 class="exceptions" id="protected-mode-exceptions">Protected Mode Exceptions<a class="anchor" href="#protected-mode-exceptions">
</a></h2>
<table>
<tr>
<td rowspan="2">#GP(0)</td>
<td>If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit.</td></tr>
<tr>
<td>If a memory operand is not aligned on a 64-byte boundary, regardless of segment.</td></tr>
<tr>
<td>#SS(0)</td>
<td>If a memory operand effective address is outside the SS segment limit.</td></tr>
<tr>
<td>#PF(fault-code)</td>
<td>If a page fault occurs.</td></tr>
<tr>
<td>#NM</td>
<td>If CR0.TS[bit 3] = 1.</td></tr>
<tr>
<td rowspan="3">#UD</td>
<td>If CPUID.01H:ECX.XSAVE[bit 26] = 0 or CPUID.(EAX=0DH,ECX=1):EAX.XSAVEC[bit 1] = 0.</td></tr>
<tr>
<td>If CR4.OSXSAVE[bit 18] = 0.</td></tr>
<tr>
<td>If the LOCK prefix is used.</td></tr>
<tr>
<td>#AC</td>
<td>If this exception is disabled a general protection exception (#GP) is signaled if the memory operand is not aligned on a 64-byte boundary, as described above. If the alignment check exception (#AC) is enabled (and the CPL is 3), signaling of #AC is not guaranteed and may vary with implementation, as follows. In all implementations where #AC is not signaled, a general protection exception is signaled in its place. In addition, the width of the alignment check may also vary with implementation. For instance, for a given implementation, an alignment check exception might be signaled for a 2-byte misalignment, whereas a general protection exception might be signaled for all other misalignments (4-, 8-, or 16-byte misalignments).</td></tr></table>
<h2 class="exceptions" id="real-address-mode-exceptions">Real-Address Mode Exceptions<a class="anchor" href="#real-address-mode-exceptions">
</a></h2>
<table>
<tr>
<td rowspan="2">#GP</td>
<td>If a memory operand is not aligned on a 64-byte boundary, regardless of segment.</td></tr>
<tr>
<td>If any part of the operand lies outside the effective address space from 0 to FFFFH.</td></tr>
<tr>
<td>#NM</td>
<td>If CR0.TS[bit 3] = 1.</td></tr>
<tr>
<td rowspan="3">#UD</td>
<td>If CPUID.01H:ECX.XSAVE[bit 26] = 0 or CPUID.(EAX=0DH,ECX=1):EAX.XSAVEC[bit 1] = 0.</td></tr>
<tr>
<td>If CR4.OSXSAVE[bit 18] = 0.</td></tr>
<tr>
<td>If the LOCK prefix is used.</td></tr></table>
<h2 class="exceptions" id="virtual-8086-mode-exceptions">Virtual-8086 Mode Exceptions<a class="anchor" href="#virtual-8086-mode-exceptions">
</a></h2>
<p>Same exceptions as in protected mode.</p>
<h2 class="exceptions" id="compatibility-mode-exceptions">Compatibility Mode Exceptions<a class="anchor" href="#compatibility-mode-exceptions">
</a></h2>
<p>Same exceptions as in protected mode.</p>
<h2 class="exceptions" id="64-bit-mode-exceptions">64-Bit Mode Exceptions<a class="anchor" href="#64-bit-mode-exceptions">
</a></h2>
<table>
<tr>
<td rowspan="2">#GP(0)</td>
<td>If the memory address is in a non-canonical form.</td></tr>
<tr>
<td>If a memory operand is not aligned on a 64-byte boundary, regardless of segment.</td></tr>
<tr>
<td>#SS(0)</td>
<td>If a memory address referencing the SS segment is in a non-canonical form.</td></tr>
<tr>
<td>#PF(fault-code)</td>
<td>If a page fault occurs.</td></tr>
<tr>
<td>#NM</td>
<td>If CR0.TS[bit 3] = 1.</td></tr>
<tr>
<td rowspan="3">#UD</td>
<td>If CPUID.01H:ECX.XSAVE[bit 26] = 0 or CPUID.(EAX=0DH,ECX=1):EAX.XSAVEC[bit 1] = 0.</td></tr>
<tr>
<td>If CR4.OSXSAVE[bit 18] = 0.</td></tr>
<tr>
<td>If the LOCK prefix is used.</td></tr>
<tr>
<td>#AC</td>
<td>If this exception is disabled a general protection exception (#GP) is signaled if the memory operand is not aligned on a 64-byte boundary, as described above. If the alignment check exception (#AC) is enabled (and the CPL is 3), signaling of #AC is not guaranteed and may vary with implementation, as follows. In all implementations where #AC is not signaled, a general protection exception is signaled in its place. In addition, the width of the alignment check may also vary with implementation. For instance, for a given implementation, an alignment check exception might be signaled for a 2-byte misalignment, whereas a general protection exception might be signaled for all other misalignments (4-, 8-, or 16-byte misalignments).</td></tr></table><footer><p>
This UNOFFICIAL, mechanically-separated, non-verified reference is provided for convenience, but it may be
inc<span style="opacity: 0.2">omp</span>lete or b<sub>r</sub>oke<sub>n</sub> in various obvious or non-obvious
ways. Refer to <a href="https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4">Intel® 64 and IA-32 Architectures Software Developer’s Manual</a> for anything serious.
</p></footer></body></html>
View git blame Copy permalink