EM64T - błękitny młoteczek?  Autor: shadow | Data: 05/07/04

Koniec czerwca 2004 roku przyniósł oficjalną zapowiedź odświeżonej edycji procesorów Xeon. Nowa technologia wykonania, wyższe zegary - nie byłoby w tym nic specjalnie ciekawego. Ot, pozornie efekt rozwoju technologii produkcji... Jest jednak coś, co na dłużej przykuwa uwagę. Mowa o wprowadzanej wraz z nowościami technologii EM64T - Extended Memory 64 Technology. Obiecując rozszerzone możliwości adresowania pamięci, Intel wkracza do walki na polu 64 bitowych układów zgodnych z x86. Zadanie nie będzie łatwe - zawodnik AMD, Opteron, jest przecież wyjątkowo silny. Co więc proponuje Intel? Co kryje się za tajemniczymi literami EM64T? Ile propozycja ta ma wspólnego z architekturą AMD64? Tym właśnie zagadnieniom poświęcony jest tekst.

Trochę historii

Maj roku 2001 był miesiącem premiery pierwszego procesora realizującego architekturę IA-64 - układu Itanium. Mówiąc krótko - debiut nie należał do specjalnie udanych - i to z kilku powodów. IA-64 było czymś zupełnie nowym. Niosło to ze sobą pewne nadzieje, ale i zagrożenia.

"Wielki" procesor Intel Itanium

Sam projekt kosztował ogromne pieniądze, pochłaniał wielkie ilości zasobów, a mimo tego termin prezentacji jednostek centralnych przesuwano kilkakrotnie. Czy zatem Itanium mogło być pewnym, bezpiecznym wyborem? Radykalne odejście od stosowanego do tej pory modelu programowego budziło uzasadniony niepokój. Co z ogromną bazą zainstalowanego oprogramowania x86? Owszem, konstrukcja Merceda (gdyż tak brzmiała nazwa kodowa procesora) przewidywała możliwość uruchomienia kodu x86, jednak w trybie tym CPU pracował nadzwyczaj powoli. Jedynym rozsądnym wyborem była więc równoczesna wymiana tak sprzętu, jak i oprogramowania. Tutaj zaś nie można było liczyć na w pełni dopracowane, wydajne kompilatory - jeśli jeszcze tempo wykonywania operacji zmiennoprzecinkowych budziło podziw, to w innych zastosowaniach nietrudno było znaleźć Itanium godnego przeciwnika. Wreszcie - ceny sprzętu były horrendalnie wysokie. Nie należy się więc raczej dziwić, że pierwsza inkarnacja IA-64 jakoś nie chciała okazać się wielkim sukcesem rynkowym.

Projekt Yamhill

Dla potentata nie było to nic wesołego - wizja świata IA-64 zaczynała się oddalać. Użytkownicy zaś coraz głośniej domagali się procesorów, które znoszą ograniczenia klasycznego x86. Co gorsza, największy konkurent giganta - AMD - ogłosił rychłe wprowadzenie rozszerzonej o elementy 64 bitowe wersji architektury x86. Robiło się niebezpiecznie - konstrukcja AMD mogła być strzałem w dziesiątkę. Zgodność z dostępnym kodem przy zachowaniu maksymalnej wydajności, i do tego niezwykle prosta ścieżka migracji - dla wymagających aplikacji. Czyż nie kusząca perspektywa? No cóż, w takiej sytuacji należało przygotować swego rodzaju plan awaryjny - pomyśleć o własnym rozszerzeniu x86. Idea była taka: zróbmy to po cichu - sprawdzimy, co i jak, a dopiero później - w razie potrzeby, jeśli AMD osiągnie sukces - uruchomimy produkcję własnych procesorów x86-64. Tak oto narodził się projekt Yamhill.

Świat dowiedział się o nim na początku roku 2002. Niestety - Yamhill przez dłuższy czas był głównie domeną plotek i spekulacji. Kilkakrotnie zaprzeczano jego istnienia. Oficjalnie Intel twierdził, że nie potrzeba kolejnej architektury, gdyż przecież dostępna jest coraz bardziej dojrzała IA-64 - w laboratoriach zaś inżynierowie testowali kolejne elementy x86-64. Przebieg wydarzeń nabrał nowego tempa kilka miesięcy później. Rok 2003 to mocne wejście procesorów Opteron - i niezwykle ciepłe przyjęcie architektury AMD64.

Coraz częściej więc wspominało się o możliwej zgodności obu konstrukcji. Czyżby po raz pierwszy w historii Intel musiał gonić AMD? Konkurent naprawdę dobrze opracował swoją ofertę. Opteron nie dość, że zazwyczaj wydajniejszy od Xeona, to jeszcze zaczął zagrażać kolejnym mutacjom Itanium. Podjęta została ostateczna decyzja - Yamhill dostaje zielone światło.

EM64T

Z początkiem roku 2004 Intel potwierdził prowadzenie prac - technologię nazwano CT (Clackamas Technology). Kilka tygodni później publicznie mówiło się już o architekturze IA-32e (od "extended") - ta wreszcie ujrzała światło dzienne pod handlową nazwą EM64T. Dobrze, ale jak to się ma do forsowanego bezustannie IA-64? Intel - trochę jak dziecko - chciałby mieć ciasteczko, ale jednocześnie je zjeść. Przyjrzyjmy się materiałom firmowym - tak, starają się one umniejszać znaczenie 64 bitowego x86. Nazwa EM64T kładzie nacisk na rozszerzenie przestrzeni adresowej - do zastosowań wymagających 64 bitowego przetwarzania wciąż polecane jest Itanium. Czyżby EM64T było więc tylko jakąś ograniczoną protezą? Otóż nie - wkrótce po publikacji dokumentacji technicznej okazało się, że EM64T to intelowski odpowiednik AMD64. Faktycznie - zasadniczo obie konstrukcje są zgodne. Czy jednak detale nie zakłócą sielanki?

Xeon Nocona z EM64T (kliknij, aby powiększyć)

Maszyna IBM i 4 x Xeon MP (kliknij, aby powiększyć)

Różnice

Nie obyło się oczywiście bez pewnych różnic. Część z nich była do przewidzenia - wszak nowe jądro Nocona to praktycznie serwerowy odpowiednik Prescotta. Wiąże się z tym obsługa zestawów instrukcji SSE-3 czy Hyper Threadingu. Niektóre za to mogą dziwić - nie widać ich w codziennej pracy komputera. Zajmijmy się nimi po kolei.

Obsługa 3DNow!

Procesory AMD umożliwiają wykorzystanie zestawów rozkazów 3DNow!. Intel nie przejął tej części specyfikacji AMD64 - ale czy polecenia te są dziś w ogóle wykorzystywane? Okazuje się, że tak - brak 3DNow! stanowić może przeszkodę przy uruchamianiu wczesnych systemów operacyjnych pisanych dla platformy AMD64. Pojawić się mogą uzasadnione wątpliwości - przecież jądro systemu nie przetwarza grafiki 3D!?... Tak, ale w skład 3DNow! Enhanced wchodzą instrukcje wstępnego pobierania danych, przeznaczonych do dalszej obróbki - prefetch/prefetchw. Używane są one w celu przyspieszenia operacji na blokach, takich jak choćby kopiowanie stron pamięci. Gdy uruchomimy taki system operacyjny na procesorze Intel, zgłoszony zostanie wyjątek - system próbował będzie wykonać niedozwoloną instrukcję. Rozwiązaniem może być korzystanie z odpowiednich instrukcji prefetch zestawu SSE.

Bit No Execute

Procesory Intel nie oferują blokady wykonywania kodu ze stron pamięci. W klasycznej architekturze x86 nie ma rozróżnienia między uprawnieniami do odczytu, a prawem do wykonywania kodu. By to zmienić, AMD wprowadziło dodatkowy bit ochrony - No Execute (NX). Ustawiając ten bit zablokować można wykonywanie kodu ze strony, nie wpływając na pozostałe operacje. Najbardziej chyba popularna metoda przejęcia kontroli nad programem - przepełnienie bufora - najczęściej kończy się próbą wykonania instrukcji zawartych w kontrolowanym przez atakującego buforze. Coraz więcej wirusów czy robaków internetowych korzysta z tego typu luk w oprogramowaniu. Jeśli bit NX zostałby w takim przypadku zastosowany, system operacyjny zatrzyma wykonywanie kodu wadliwie działającego programu. Stąd też wielkie marketingowe znaczenie tej cechy procesorów AMD - często mówi się o "ochronie antywirusowej procesorów AMD". Nie jest to niestety żaden złoty środek - mając kontrolę nad buforem i tak zwykle można zdobyć uprawnienia z jakimi działa atakowany program, wymaga to jednak trochę więcej zachodu. Niemniej jednak to krok w dobrą stronę - zatem i kolejne wydanie jednostek EM64T wzbogacone zostanie o ten typ ochrony - jednak pod nazwą XD.

Szybkie wywołania systemu operacyjnego

Dostęp do usług jądra systemu odbywa się zazwyczaj przy pomocy systemu tzw. przerwań programowych - transfer sterowania dokonywany jest przez rozkaz int. Nie jest to metoda specjalnie efektywna. W najgorszej sytuacji znajdują się posiadacze procesorów NetBurst - tam koszty wywołań są nawet kilka razy wyższe, niż w przypadku poprzednich generacji jednostek centralnych. Okazuje się jednak, że architekci systemów operacyjnych dysponują alternatywnymi, szybszymi metodami przekazywania kontroli. Firma AMD zaproponowała parę rozkazów syscall/sysret, Intel - sysenter/sysexit. Ich zastosowanie pozwala zwiększyć wydajność wywołań systemowych nawet kilkakrotnie. Problemem może być dostępność danej metody w wybranym trybie pracy - dozwolone kombinacje przedstawione są w tabelce.

Instrukcja cmpxchg16b

Procesory EM64T oferują rozszerzoną, 16 bajtową wersję rozkazu cmpxchg (compare and exchange - porównania i zamiany). Instrukcje te wykorzystywane są głównie w połączeniu z przedrostkiem lock, który gwarantuje wyłączność w dostępie do pamięci na czas ich wykonania. Jest to szczególnie przydatne przy synchronizacji dostępu do zasobów. Niektóre algorytmy tego typu wymagają operacji na obiektach o rozmiarze równym dwóm wskaźnikom - w tym przypadku będzie to 128 bitów, czyli właśnie 16 bajtów. Można się spodziewać implementacji tej instrukcji w kolejnych wersjach procesorów AMD.

Zapisywanie stanu FPU

Gdy zajdzie potrzeba zmiany kontekstu pracy procesora, konieczne jest zapisanie zawartości rejestrów - by później można je było odtworzyć. Służą temu instrukcje fxsave oraz fxrstor. Zapisywany jest stan rejestrów x87/MMX oraz SSE. Czasem jednak przydatna jest krócej działająca forma - pomijająca zapamiętanie stanu rejestrów SSE. Taki właśnie tryb pracy omawianych instrukcji oferują procesory AMD64. Na procesorach firmy Intel nie ma możliwości wykorzystania tego trybu.

Poszukiwanie bitów w zerze

Instrukcje bsf (bit scan forward) oraz bsr (bit scan reverse) szukają pierwszego wystąpienia ustawionego bitu w danym operandzie. Wynik poszukiwań (tj. indeks znalezionego bitu) zapisywany jest w rejestrze. Problem pojawia się, gdy szukamy pierwszego zapalonego bitu w zerze - oba procesory ustawiają wtedy flagę zera (ZF - Zero Flag). Procesory AMD nie zmieniają w takiej sytuacji rejestru mającego przechowywać wynik. Dokumentacja procesorów Intela określa z kolei wynik słowem niezdefiniowany. Dotyczy to zawsze całego rejestru - nawet przy operacji na jego 32 bitowej połówce. Taka jest przynajmniej oficjalna wersja Intela - póki co procesory te zachowują się identycznie jak chipy AMD.

Skoki bliskie z przedrostkiem 66h

Przedrostek 66h oznacza zmianę wielkości operandu - jeśli przykładowo procesor pracując w trybie 32 bitowym odnajdzie bajt 66h, przy następnej instrukcji oczekiwał będzie danej 16 bitowej. Działa to również i w drugą stronę. Dla nas bardziej interesujące jest zachowanie procesorów przy rozkazach skoków bliskich. Instrukcje te zmieniają wartość wskaźnika instrukcji - tutaj zaś próbować będziemy sztucznie go ograniczyć. Zamiast skoku do wysokiego obszaru pamięci, w przypadku procesorów AMD ograniczymy wynikowy adres do 16 bitów (pierwsze 64 kilobajty przestrzeni adresowej). Adresy takie nie są dostępne w większości nowoczesnych systemów operacyjnych, rozkaz taki nie ma więc większego sensu. Procesory EM64T po prostu nie uznają takiego rodzaju skoków za dopuszczalne instrukcje, i zgłaszają błąd.

Rejestry MSR (Machine Specific Registers)

Każdy współczesny procesor x86 dysponuje zestawem określających głównie działania sprzętu rejestrów MSR. Są one - jak nazwa wskazuje - specyficzne dla danej rodziny procesorów. Zestaw rejestrów MSR implementowanych w procesorach AMD64 różni się od zestawu obecnego w jednostkach EM64T.

Flagi cpuid

Rozkar cpuid identyfikuje procesor, oraz informuje o jego specyficznych możliwościach. Poza oczywistymi różnicami (np. bity określające wsparcie HT), firma Intel zmieniła trochę sposób, w jaki zwracane są informacje identyfikacyjne procesora. Układy AMD przy tzw. rozszerzonych wywołaniach cpuid zwracają wszystkie bity opisujące procesor (to, co dają zwykłe cpuid plus dodatkowe informacje o trybie 64 bitowym i wsparciu syscall/sysret). EM64T musiało się jakoś wyróżnić - produkt Intela zwraca tylko dodatkowe informacje. Powodować to może trudności przy wykrywaniu zdolności procesora do pracy w nowym trybie - stąd pierwsze doniesienia o braku możliwości uruchomienia 64 bitowych systemów na Noconach. Ot, taki indywidualizm.

Rozkazy lahf/sahf

Instrukcje te służą do modyfikacji dolnego bajtu rejestru flag. Nie są one obsługiwane przez układy EM64T. Ciekawsza jest sytuacja w chipach AMD - dokumentacja twierdzi, że można z nich korzystać, ale próba ich wykonania kończy się zgłoszeniem wyjątku.

Translacja adresów IO

Samo zagadnienie nie dotyczy procesorów, lecz bardziej układów im towarzyszących - biorąc jednak pod uwagę fakt integracji mostka północnego z układami AMD, można uznać go za różnicę między z rozwiązaniem Intela. O co chodzi? Otóż wiele dostępnych obecnie urządzeń (karty sieciowe, sterowniki dysków, ale i układy grafiki), nawet pracujących z 64 bitową szyną danych, nie potrafi zaadresować więcej niż 4 GB pamięci.

Pojawia się tu poważny problem - co zrobić, gdy chcemy przykładowo przesłać blok z dysku do pamięci, pod adres powyżej 4 GB. Bez dodatkowych rozwiązań trzeba zaalokować bufor w przestrzeni dolnych 4 GB, po czym skopiować odczytane dane. Nie jest to ani wydajne, ani eleganckie - mogą też wystąpić problemy z ilością pamięci w "niskim" obszarze. Niestety - tak to wygląda przy użyciu procesorów EM64T z obecnymi chipsetami.

Sprawa nie dotyczy wyłącznie zewnętrznych urządzeń - identycznie zachowują się np. wbudowane w intelowskie mostki kontrolery IDE. AMD rozwiązało problem trochę inaczej - mechanizm IOMMU przekształca wysokie adresy przy pracy z ograniczonymi do 32 bitów urządzeniami. W ten sposób pamięć może faktycznie znajdować się poza barierą 4 GB, nie trzeba też kopiować danych. Co ciekawe, funkcjonalność ta dodana została do jądra Opterona na prośbę developerów jądra Linuksa - tak naprawdę jest to swego rodzaju AGP GART na sterydach ;) Łyżką dziegciu w beczce miodu mogą być problemy kontrolerów VIA z IOMMU przy obecności ponad 3 GB pamięci w systemie...

Wszystko? Większość...

W tej chwili ulec można złudnemu wrażeniu, że praktycznie żaden program AMD64 nie da się uruchomić na układach Intela. Nic bardziej mylnego - wymienione różnice dotyczą głównie systemów operacyjnych, programy poziomu użytkownika mogą wcale ich nie zauważać. Nie jest więc źle - doczekaliśmy się jednego standardu procesorów x86-64. To cieszy. Ci, których nie mogły przekonać wydajność czy skalowalność procesorów AMD, być może teraz dadzą się namówić na AMD64 w wydaniu Intela. Tak - praktycznie Intel mógłby na swoich układach umieszczać notkę "AMD64 compatible". Wiadomo jednak, że prędzej zamarzną pewne niezwykle ciepłe obszary zaświatów, niż dojdzie do czegoś podobnego... ;)

Polub TwojePC.pl na Facebooku

Rozdziały: EM64T - błękitny młoteczek?   Wyświetl komentarze do artykułu »