1. Zuhause
  2. Frage und Antwort
  3. AVX512 Vektorlänge und SAE Steuer

AVX512 Vektorlänge und SAE Steuer

2016-04-23 11 views
5

Meine Frage betrifft EVEX-kodierte verpackt reg-reg Anweisungen ohne semantische Rundung, die SAE Kontrolle ermöglichen (Unterdrückt alle Ausnahmen), wie VMIN *, VCVTT *, VGETEXT *, VREDUCE *, VRANGE * etc. Intel deklariert SAE-Awareness nur mit voller 512bit Vektorlänge, zAVX512 Vektorlänge und SAE Steuer

aber ich sehe keinen Grund, warum SAE nicht auf Anweisungen angewendet werden konnte, bei denen Xmm- oder Ymm-Register verwendet werden.

In Kapitel 4.6.4 von Intel Instruction Set Extensions Programming Reference Tabelle 4-7 sagt, dass in Anweisungen ohne semantischen Bit EVEX.b Rundungs ​​gibt an, dass SAE angelegt wird, und die Bits EVEX.L'L explizite Vektorlänge angeben:

00b: 128bit (XMM) 
01b: 256bit (YMM) 
10b: 512bit (ZMM) 
11b: reserved

so sollte ihre Kombination legal sein.

jedoch assembliert NASM vminpd zmm1,zmm2,zmm3,{sae} als 62F1ED185DCB, dh EVEX.L'L = 00b, EVEX.b = 1 ist, die durch Rück NDISASM 2.12 vminpd xmm1,xmm2,xmm3 zerlegt

NASM weigert zu montieren vminpd ymm1,ymm2,ymm3,{sae} und NDISASM disassembliert 62F1ED385DCB (EVEX.L'L = 01b, EVEX.b = 1) als vminpd xmm1,xmm2,xmm3

ich frage mich, wie funktioniert Ritter Landing CPU ausführen VMINPD ymm1, ymm2, ymm3{sae} (als 62F1ED385DCB montiert, EVEX.L'L = 01b, EVEX.b = 1):

  1. CPU löst eine Ausnahme aus. Intel doc Tabelle 4-7 ist irreführend.
  2. SAE ist in Wirklichkeit, CPU arbeitet mit xmm nur, wie in Skalar Operationen. NASM und NDISASM machen es richtig, Intel Dokumentation ist falsch.
  3. SAE wird ignoriert, CPU arbeitet mit 256 Bit gemäß VMINPD Spezifikation in Intel Doc. NASM & NDISASM sind falsch.
  4. SAE ist tatsächlich, CPU arbeitet mit 256 Bits, wie in Befehlscode angegeben. NASM und NDISASM sind falsch, Intel Doc muss zusätzliche dekorieren xmm/ymm Anweisungen mit {sae}.
  5. SAE ist tatsächlich, CPU arbeitet mit implizierten voller Vektorgröße 512 Bits, unabhängig von EVEX.L'L, als ob statische Rundungen {er} zulässig wären. NDISASM und Intel doc Tabelle 4-7 sind falsch.

Quelle

2016-04-23 vitsoft

Antwort

4

Ihre VMINPD ymm1, ymm2, ymm3{sae} Anweisung ist ungültig. Nach Befehlssatz Referenz für MINPD im Intel Architecture Instruction Set Extensions Programming Reference (February 2016) nur die folgenden Codierungen sind möglich:

66 0F 5D /r     MINPD xmm1, xmm2/m128 
VEX.NDS.128.66.0F.WIG 5D /r VMINPD xmm1, xmm2, xmm3/m128 
VEX.NDS.256.66.0F.WIG 5D /r VMINPD ymm1, ymm2, ymm3/m256 
EVEX.NDS.128.66.0F.W1 5D /r VMINPD xmm1 {k1}{z}, xmm2, xmm3/m128/m64bcst 
EVEX.NDS.256.66.0F.W1 5D /r VMINPD ymm1 {k1}{z}, ymm2, ymm3/m256/m64bcst 
EVEX.NDS.512.66.0F.W1 5D /r VMINPD zmm1 {k1}{z}, zmm2, zmm3/m512/m64bcst{sae}

Beachten Sie, dass nur die letzte Version mit einem {sae} Suffix angezeigt wird, was bedeutet, es ist die einzige Form der Anweisung ist Sie darf es mit benutzen. Nur weil die Bits existieren, um eine bestimmte Anweisung zu codieren, bedeutet dies nicht, dass sie gültig ist.

Beachten Sie auch Abschnitt 4.6.3, SAE-Support in EVEX, macht deutlich, dass SAE nicht auf die 128-Bit oder 256-Bit-Vektoren gilt:

EVEX Codiersystem ermöglicht arithmetische Gleitkommabefehle codiert ohne Rundung semantische werden mit das SAE-Attribut. Diese Fähigkeit gilt für skalare und 512-Bit-Vektorlängen, nur Register-zu-Register, unter Einstellung EVEX.b. Wenn EVEX.b festgelegt ist, wird "alle Ausnahmen unterdrücken" impliziert. [...]

Ich bin mir nicht sicher, aber ob Ihre handgefertigte Anweisung Ausnahme ungültigen Befehlscode erzeugen würde, wenn die EVEX.b Bit wird einfach ignoriert werden, oder wenn die EVEX.L'L Bits werden ignoriert. EVEX codiert VMINPD Anweisungen gehören zum Typ E2 Ausnahmeklasse, und gemäß Tabelle 17.4, Typ E2 Klasse Ausnahmebedingungen kann der Befehl eine #UD Ausnahme in einem der folgenden Fälle erzeugen:

  • Staat Anforderung, Tabelle 4-8 nicht erfüllt.
  • Vom Opcode unabhängige ID-Bedingung in Tabelle 4-9.
  • Operand Codierung #UD Bedingungen in Tabelle 4-10.
  • Opmask Codierung #UD Bedingung von Tabelle 4-11.
  • Wenn EVEX.L'L! = 10b (VL = 512).

Nur der letzte Grund scheint hier zu bewerben, aber es würde bedeuten, dass Ihre Anweisung #UD Ausnahme mit oder ohne {sae} Modifikator erzeugen würde. Da dies den erlaubten Kodierungen in der Anweisungszusammenfassung direkt widerspricht, bin ich mir nicht sicher, was passieren würde.

Quelle

2016-08-15 18:20:55

+0

Gut, dass die Dokumentation sagt, Sie können es nicht tun, unabhängig von der Codierung Details. Die Antwort von Mysticial weist jedoch darauf hin, dass sich EVEX.L'L mit EVEX.RC überschneidet, und EVEX.b wählt aus, mit welcher Version sie interpretiert werden. –

+0

@PeterCordes Außer, wie in der Frage erläutert, widerspricht Tabelle 4-7 dieser Interpretation. Es besagt, dass bei "FP-Anweisungen ohne Rundungssemantik #XF verursachen kann", dass EVEX.b "SAE Control" auswählt, während EVEX.L'L die Vektorlänge bestimmt und EVEX.RC nicht anwendbar ist. Nach der Tabelle bestimmt der Befehlstyp die Interpretation von 'P2 [6: 5]'. So hat zum Beispiel 'VMINPD ymm1, ymm2, [rax] {1to8}' EVEX.b gesetzt, während EVEX.L'L 01b ist und EVEX.RC ist N/A. Das OP-Problem ist, dass dies nicht für '{sae}' funktioniert. Die Kodierung, die er will, existiert, aber es ist einfach nicht erlaubt. –

+0

Zunächst stimmte ich Ihrer Antwort nicht zu. Aber nachdem ich Tabelle 4-7 ausführlich durchgegangen bin, habe ich festgestellt, dass das PDF entweder unvollständig ist oder sich selbst widerspricht. FP-Befehle haben das Konzept der "Rundungssemantik". Aber es gibt keine Liste im Dokument, die angibt, welche Anweisungen fehlen. Tabelle 4-7 besagt, dass 'P2 [6: 5]' immer als 'EVEX.L'L' für FP-Anweisungen interpretiert wird, denen" Rundungssemantik "fehlt. – Mysticial

Verwandte Themen

 Verwandte Themen