AVX512 długość wektora i kontrola SAE

Question

Moje pytanie dotyczy EVEX zakodowane spakowane instrukcją reg-reg bez zaokrąglania semantycznej który umożliwi kontrolę SAE (Usunięcie wszystkich wyjątków), takich jak Vmin *, VCVTT * VGETEXT * VREDUCE *, VRANGE * itd. Intel deklaruje SAE-aware tylko z pełną długością wektora 512-bitowego, np.

VMINPD xmm1 {k1}{z}, xmm2, xmm3 
VMINPD ymm1 {k1}{z}, ymm2, ymm3 
VMINPD zmm1 {k1}{z}, zmm2, zmm3{sae} 

, ale nie widzę powodu, dla którego nie można zastosować SAE do instrukcji, w których używane są rejestry xmm lub ymm.

W rozdziale 4.6.4 z Intel Instruction Set Extensions Programming Reference Tabela 4-7 mówi, że w instrukcji bez zaokrąglania semantycznej bitowy EVEX.b SAE określa, że ​​jest stosowana, a bity EVEX.L'L określić wyraźny długość wektora:

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

, więc ich połączenie powinno być legalne.

Jednakże NASM montuje vminpd zmm1,zmm2,zmm3,{sae} jako 62F1ED185DCB tj EVEX.L'L = 00b, EVEX.b = 1, która jest zdemontowana z powrotem przez NDISASM 2.12 vminpd xmm1,xmm2,xmm3

NASM odmawia montażu vminpd ymm1,ymm2,ymm3,{sae} i NDISASM demontuje (62F1ED385DCB EVEX.L'L = 01b, EVEX.b = 1) vminpd xmm1,xmm2,xmm3

zastanawiam się w jaki sposób procesor Knights Landing wykonać VMINPD ymm1, ymm2, ymm3{sae} (montowane jako 62F1ED385DCB, EVEX.L'L = 01b, EVEX.b = 1):

1. Procesor generuje wyjątek. Intel doc Tabela 4-7 wprowadza w błąd.
2. SAE działa, procesor działa z tylko xmm, tak samo jak w przypadku operacji skalarnych . NASM i NDISASM robią to dobrze, dokumentacja Intela jest błędna.
3. SAE jest ignorowane, procesor pracuje z 256 bitami zgodnie ze specyfikacją VMINPD w dokumencie Intel. NASM & NDISASM są nieprawidłowe.
4. SAE działa, procesor działa z 256 bitów zgodnie z kodem instrukcji . NASM i NDISASM są w błędzie, dokumentacja Intela musi być z dodatkowymi ozdobami instrukcji xmm/ymm z {sae}.
5. SAE działa, procesor działa z dorozumianymi pełnymi rozmiarami wektorowymi 512 bitów, niezależnie od EVEX.L'L, tak samo, jakby dozwolone były statyczne zaokrąglenia {er} . NDISASM i Intel doc Tabela 4-7 są błędne.

Answer 1

Twoja instrukcja VMINPD ymm1, ymm2, ymm3{sae} jest nieprawidłowa. Według Zestaw instrukcji dla MINPD w Intel Architecture Instruction Set Extensions Programming Reference (February 2016) Dozwolone są tylko następujące kodowanie:

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} 

Zauważ, że tylko ostatnia wersja jest pokazany z {sae} przyrostek, co oznacza, że ​​jest to jedyna forma instrukcji ty można go używać z. Tylko dlatego, że bity istnieją, aby zakodować konkretną instrukcję, nie oznacza to, że jest ona ważna.

Należy również zwrócić uwagę na punkt 4.6.3, SAE Pomoc w EVEX, jasno wynika, że ​​nie stosuje się SAE 128-bitowe lub 256-bitowe wektory:

System kodowania EVEX pozwala instrukcje arytmetyczne zmiennoprzecinkowych bez zaokrągleń semantycznej do zakodowania z atrybut SAE. Ta możliwość ma zastosowanie do skalarnych i 512-bitowych długości wektorów, tylko do rejestracji w rejestrze, przez ustawienie EVEX.b. Po ustawieniu EVEX.b, domyślnie "tłumi wszystkie wyjątki". [...]

Nie jestem jednak pewien, czy twoje ręcznie spreparowane instrukcje wygenerowałyby wyjątek Niewłaściwy kod, jeśli bit EVEX.b zostanie po prostu zignorowany, lub jeśli bity EVEX.L'L będą ignorowane. EVEX zakodowane instrukcje VMINPD należą do typu E2 klasy wyjątku, zgodnie z tabelą 4-17, typ E2 Klasa Warunki wyjątku instrukcja może generować wyjątek #UD w każdym z następujących przypadków:

• państwo wymaganie, Tabela 4-8 nie została spełniona.
• Tryb niezależny od kodu niezależnego od kodu w tabeli 4-9.
• Kodowanie operandów #UD w tabeli 4-10.
• Kodowanie opmaskowe # ZAN z tabeli 4-11.
• Jeśli EVEX.L'L! = 10b (VL = 512).

Tylko że ostatni powód wydaje się tu zastosowania, ale oznaczałoby to, że instrukcja będzie generować wyjątek #UD z lub bez modyfikatora {sae}. Ponieważ wydaje się to bezpośrednio sprzeczne z dozwolonymi kodowaniami w podsumowaniu instrukcji, nie jestem pewien, co by się stało.