XSAVEOPT
XSAVEOPT és un membre optimitzat de la família de desat d'estat estès de x86. Les seves optimitzacions permeses es basen en el contracte arquitectònic de gestió d'estat i no la converteixen en una instrucció de còpia arbitrària de memòria intermèdia.
El que cal saber
XSAVEOPT és un membre optimitzat de la família de desat d'estat estès de x86. Les seves optimitzacions permeses es basen en el contracte arquitectònic de gestió d'estat i no la converteixen en una instrucció de còpia arbitrària de memòria intermèdia.
Com funciona
En comparació amb un desat d'estat estàndard, XSAVEOPT pot evitar escriure alguns components segons el seguiment d'inicialització i de modificació. El programari ha de seguir les regles definides d'inicialització i restauració d'imatges. Un byte no modificat a la destinació no és necessàriament una prova que un component s'hagi desat incorrectament.
On és útil
Una via de gestió de context del SO pot reduir el trànsit innecessari de memòria quan l'estat dels registres estesos no ha canviat. Les aplicacions haurien de confiar en la implementació del sistema operatiu llevat que tinguin un requisit documentat de gestió d'estat de baix nivell.
Com comprovar el suport i l'habilitació
Amb XSAVE i el rang de fulles adequat disponible, el bit 0 de CPUID.0DH.01H:EAX enumera XSAVEOPT. Comproveu els components d'estat habilitats i els requisits de memòria intermèdia per separat, i seguiu l'emparellament de desat/restauració prescrit per l'arquitectura.
Les funcions de gestió d'estat són principalment responsabilitat del SO i de l'entorn d'execució. Els búfers, les màscares, les mides de components, l'alineació i les regles de restauració han de coincidir amb l'arquitectura i el mode d'execució. Desar només un subconjunt pot corrompre el codi que utilitza estat addicional habilitat.
El que la característica no estableix
XSAVEOPT no és XSAVEC ni XSAVES i no implica tots els formats posteriors de desat d'estat. Reutilitzar una memòria intermèdia sense respectar el contracte d'imatge d'estat pot produir restauracions incorrectes. L'optimització no estableix guanys de rendiment a nivell d'aplicació.
Compatibilitat i rendiment a la pràctica
La detecció de funcionalitats a nivell d'aplicació ha d'utilitzar una interfície d'entorn d'execució mantinguda quan sigui possible. Distingiu el suport de maquinari de l'habilitació pel SO i, per a funcionalitats dinàmiques, del permís de procés. Una etiqueta de CPU per si sola no pot establir que una seqüència arbitrària de desat/restauració sigui correcta.
Una llista de verificació pràctica
- Enregistreu el model exacte de processador o de plataforma i les versions d'aplicació, SO i entorn d'execució implicades. Conserveu la redacció de l'error o del requisit real.
- Comproveu la referència del fabricant per a aquest model exacte, i després inspeccioneu la capacitat efectiva i l'estat habilitat en l'entorn on s'executa el programa.
- Compareu cada requisit del binari o dorsal seleccionat. Una característica amb un nom similar, un àlies o una etiqueta de tecnologia àmplia no és suficient.
- Confirmeu que l'aplicació ha seleccionat la implementació prevista. Utilitzeu els seus diagnòstics documentats i una alternativa compatible quan no es compleixin els requisits.
- Feu un únic canvi admès a la vegada i repetiu la mateixa càrrega de treball. Manteniu disponibles la configuració original i la via de recuperació.
Si la característica apareix a la llista però el programari no la pot utilitzar
Comenceu pel component exacte que falla. Una base de dades de maquinari descriu la capacitat registrada; el sistema operatiu o l'hipervisor poden exposar un entorn efectiu diferent. Un error d'instrucció il·legal també requereix investigar la instrucció defectuosa real i la compilació del binari, perquè una corrupció o una instrucció no admesa no relacionada poden produir un símptoma similar.
Instal·leu la versió d'aplicació, controlador o entorn d'execució admesa per a la plataforma exacta, i utilitzeu la compilació base o alternativa documentada pel fabricant si cal. Una actualització de programari no pot crear una instrucció que li manqui al processador. Els canvis de microprogramari i de polítiques de seguretat han de seguir el procediment del fabricant del sistema i un pla de recuperació en lloc d'una recepta genèrica d'optimització.
Fonts i abast d'aquesta explicació
Intel 64 and IA-32 Architectures Software Developer's Manual · Linux kernel: using XSTATE features in user space
Aquestes referències estableixen el comportament arquitectònic i els requisits de programari. No verifiquen de manera independent cada valor de característica en una pàgina de model de maquinari enllaçada. Per al suport de models, utilitzeu l'evidència del fabricant d'aquesta pàgina i comproveu la configuració efectiva del sistema. Aquest article no proporciona cap data de prova de referència, certificació o revisió independent.
Fonts i verificació
Propietat editorial: Feex. No s'ha registrat cap data de revisió independent. Com investiguem.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Els volums 1 i 2 descriuen les famílies d'instruccions anomenades i CPUID; el volum 3 descriu l'estat, la paginació, VMX i els controls de protecció. La documentació d'arquitectura no estableix el suport per a un model en particular.
- Linux kernel: using XSTATE features in user space · Estat vectorial habilitat pel SO, estat de tessel·les habilitat dinàmicament, requisits de pila de senyals i flux de permisos AMX. El comportament específic de Linux no és una promesa sobre un altre SO.
Ha estat útil aquest article?
Un sí o un no és suficient. Trieu un motiu si voleu, o afegiu una breu nota.
Gràcies. Això ens ajuda a millorar aquesta pàgina.