Autor: Andrzej Karpinski (KARPIO_at_golem.umcs.lublin.pl)
Data: Tue 01 Apr 1997 - 22:57:13 MET DST
>Ze intel laskawie zrobil polowe tego, co zrobic powinien na poczatku
>procesu projektowania procesora - testowanie bitow. Chwala mu za to,
>lepiej pozno niz wcale. Ale ja bym chcial jeszcze, zeby tak mozna to
>robic na DOWOLNYM z rejestrow (ze o wyjsciu z rejestrow innych jak
>akumulator nie wspomne)
Wielce Szanowny i Drogi Jasnie Panie Darek!
Znow widze jedynie agresje w Twoich wypowiedziach i platanine
przedziwnych strzepkow informacji. Niestety nie wykazales znajomosci
chociazby ogolnej zasady, ktorej ma sluzyc MMX - o co prosilem. Nie wiem
wiec, czy powinienem nada kontynuowac z JW Panem Darkiem dyskusje.
Pozwole jednak sobie napisac slow kilka by uscislic pare informacji, mam
nadzieje z korzyscia dla Pana Darka i innych.
Z Twoich listow wynika, ze nie wiesz co to jest MMX i czemu ma sluzyc.
Spiesze z wyjasnieniami. MMX jest dodatkowa jednostka przetwarzajaca
wewnatrz procesora. Operuje na, co by nie mowic, bardzo pojemnych
rejestrach koprocesora, a przy okazji taki manewr pozwala na pelna
kompatybilnosc z istniejacym oprogramowaniem, takze z uwzglednieniem
sytuacji w rodzaju przelaczanie taskow, korzystajacych z roznych
jednostek. Jednostka MMX przypomina specyficzny procesor RISC - uklad DSP
przeznaczony do przzetwarzania specyficznych danych w specyficzny sposob.
SIMD - jest to nowa technologia, polegajaca na tym, ze pojedyncza
instrukcja moze dotyczyc wiecej niz jednego slowa/rejestru. Jest to wiec
jakby nad-RISC. Przyklad:
pobranie danej z RAMu do rejestru FPU - 2(3) takty
zakladajac, ze poniewaz mamy dwie niezalezne jednostki MMX mozemy wykonac
dwie takie instrukcje w danej chwili mozemy w uproszeniu napisac, ze
zajmuje to polowe mniej czasu, czyli 1 takt.
"dana" jest to pelne 64 bity informacji, chociazby o obrazie (czyli np.
4ry pixelki z 16-bitowa glebia koloru). zaladowanie tych danych do
rejestru (8miu pizxeli obrazu z 16 bit kolorem) zajelo 2 takty!
dalej:
powtarzamy te operacje dla drugiego rejestru. poniewaz operacje nastepuja
bezposrednio po sobie i dotycza roznych rejestrow rzeczywiscie mozna
wykonac je jednoczesnie. mamy wiec po dwoch taktach zaladowane do
rejestrow koprocesora 8 pixli z 16-bitowym kolorem.
i teraz (!) - XORujemy przez siebie te dwa rejestry, co zajmuje (!) dwa
takty. wynik dostajemy np. w trzecim rejestrze. co to daje? ano mamy
przenikniecie sie 16-bitowych obrazow, wykonane dla 8 pixli dwoch
roznych obrazkow, ktore zajelo nam... 4 takty!
biorac pod uwage czestotliwosc pracy procesora okazuje sie to byc
wystarczajace do zrobienia np. animacji przenikajacych sie obrazkow badz
znacznego udoskonalenia przetwarzania obrazow, dzieku czy video.
SIMD to ewidentnie RISC, a nawet cos wiecej. mamy bardzo niewielka ilosc
instrukcji (57 wraz z instrukcjami sterujacymi), dwa sposoby adresowania
danych, operacje bezposrednio na pamieci dotycza jedynie wyrzucenia
rejestru do pamieci, badz wczytania komorek pamieci do rejestru.
pojedyncza instrukcja moze dotyczyc wiecej niz jednego rejestru (czyli
zmniejsza sie ilosc taktow i wielkosc kodu).
MMX to nic innego jak polaczenie techniki RISC z idea cyfrowego procesora
sygnalowego. Ze klasyczne DSP moga byc duzo szybsze? ale nie mozna ich
wszedzie zastosowac...
Te kilkadzieisat zaledwie instrukcji to wlasnie operacje mnozenia,
dodawania, przesuwania bitow, porownywania sporych ilosci danych (64bity
i wiecej) pojedynczymi, krotkimi instrukcjami. Nie wiem skad rewelacje o
braku testowania bitow, ktore juz posiadal starenki 4004 ;)
Polecam lekture listy rozkakow 8086, chociazby taka fajna czarno-zolta
ksiazke opisujaca cala rodzinke x86 do i486 wlacznie (nie pamietam tytulu
- przepraszam).
>Nie. Pudlo! SunSparc 4, po swietach bedzie Ultra. Prywatnie badziewne
>pentium (jak sie nie ma co sie lubi, to sie lubi co sie nie ma... )
Dla ulatwienia dodam, ze PentiumPro i dowolny U*X da ci wieksze
mozliwosci niz Spark w twoim Sunku 4 ;) Oczywiscie chyle czolo przed
UltraSparkiem, aczkolwiek podejrzewam, ze Intel nie zasypuje gruszek w
popiele, zas wyniki testow nie potwierdzja jakiejs miazdzacej (powiedzmy
3-krotnej) przewagi Sparka nad Prosiakiem...
>A wsp<˙y licznik rozkazow utrudnia (wlasciwie uniemozliwia)
>rownolegla prace obu jednostek. A przy okazji - czy powyzej 386
>zrealizowano wreszcie automatyczne blokowanie jednostki
>staloprzecinkowej w czasie operacji zmiennoprzecinkowych, czy nadal
>obowiazek zapewnienia ze sie nie pobija o ten wspolny licznik spoczywa
>na programistlgcie?
Nie, koprocesor (MMX) i CPU moga i nawet powinny pracowac jednoczesnie.
Problem jedynie w takim napisaniu programu, aby nie wychodzily z tego
glupoty z jednej strony, a z drugiej by CPU nie czekal bezczynnie na dane
z koprocesora. Najogolniej programista (wylaczajac systemowca ktory
siedzi nad krytycznym 15kb kernela) nie musi nawet wiedziec jak to
zorganizowac, bo robi to za niego kompilator. Nie wyobrazam sobie pisania
czegokolwiek w asemblerze przy dzisiejszym skomplikowaniu programow (nad
czym nota bene ubolewam).
Przyczepiales sie arytmetyki BCD - a zwroc uwage, ile tranzystorow
potrzebowal na to 8086... mial ich wszystkich kilkanascie tysiecy ;) i
wykonywal rozkazy BCD w 20 taktow kazdy. PPro potrzebuje na to polowe
tego czasu, czyli zalozmy, ze ilosc tranzystorow do obslugi instrukcji
BCD wzrosla pieciokrotnie. Wybacz, ale dodatkowe 50tys tranzystorow nie
zrobi roznicy w zadnym ukladzie, ani pod wzgledem poboru pradu, ani pod
wzgledem temperatury, ani pod zadnym innym. A czasem dla programisty
okazuje sie to calkiem wygodne. Argument przeciw BCD i za RISC odpada -
niewielki to bowiem naklad srodkow, nawet jesli i praktyczna przydatnosc
watpliwa. Poza tym utrzymuje sie to bardziej ze wzgledu na kompatybilnosc
niz na realna potrzebe stosowania. Tego wymagaja uzytkownicy - takze Ty!
Zaleznosc od siebie jednostek FPU i MMX to wymog kompatybilnosci z jednej
strony, z drugiej zas strony przywyczajenie programistow do pewnego
porzadku. Skoro przelaczanie jednostek zajmuje 30 taktow, to nalezy je
wykonywac mozliwie rzadko. I tak tez sie robi. Np. najpierw liczy sie 3d
(CPU + FPU), a potem wpycha sie dane z ew. znieksztalceniami na ekran
(CPU + MMX). Nie ma potrzeby aby robic to jednoczesnie.
>A co to sa "instrukcje MMX"? testowanie bitow? Ustawianie bitow?
>PowerPC w ogole nie ma wiekszosci z instrukcji stanowiacych dume
>intela - jako RISC ma tylko niezbedne minimum instrukcji
>wykorzystywanych najczesciej, reszta to program. Warto to zauwazyc,
>jak sie czyta liste instrukcji. Jak rowniez, ile ktora z instrukcji
>zajmuje cykli - po to wymyslono RISC, zeby procesor wszystko
>realizowal sprzetowo, a nie przez mikrokod.
Co to sa instrukcje MMX opisalem powyzej. Bardziej przypominaja RISC niz
same RISC ;)) Wielkie rejestry i znikoma ilosc kodu operujaca na duzej
ilosci informacji, czyli to o cym piszesz... ;->>
Do testowania bitow takze ustosunkowalem sie, piszac ze to kompletna
bzdura (po coz bylyby rejestry sterujace (znacznikow) jesli nie mozna
testowac/ustawic dowolnego bitu??!!).
Idea procesora RISC powstala jakis czas temu i przez pewien czas wydawalo
sie, ze jest to przyszlosc. Obecnie nie jest to juz tak calkiem
jednoznaczne i nawet rodziny procesorow do niedawna zaliczane do ukladow
RISC obecnie sa bardziej CISC niz wiele klasycznych CISCow.
Ale po kolei. Od dawna znano takie rzeczy jak rownoczesna praca kilku
czesci procesora nad jedna instrukcja, czyli przetwarzanie instrukcji w
jakby "potoku". Juz 8086 mial takie mozliwosci - jednostka pobierajaca
rozkazy do kolejki, jednostka wykonawcza itd: rownoczesnie kilka czesci
pracowalo niezaleznie nad przetwarzaniem rozkazow. Pozniej rozwinieto to
do przetwarzania potokowego i procesora superskalarnego. Instrukcje
rozbija sie na wiele malych podinstrukcji i wykonuje kroczkami angazujac
mozliwie mala czesc zasobow ukladu. Rownoczesnie powiela sie takie
uklady, aby w tym samym czasie procesor mogl zajac sie maksymalnie duza
iloscia instrukcji. Dzieki temu osiagnieto juz w 486 mozliwosc
przetwarzania 1 instrukcji/takt, 2 instrukcji/takt w Pentium i 3-4
instrukcji/takt w PentiumPro. Z drugiej strony, pare l;at temu, byly to
bardzo skomplikowane i niezbyt opanowane mechanizmy, wiec duzo prosciej
bylo je robic na prostych ukl;adach niz na bardziej skomplikowanych. I tu
jest wlasnie sila ukladow RISC - stosowano w nich znacznie bardziej
nowoczesne mechanizmy przetwarzania instrkucji niz w ukladach CISC, gdyz
w CISC nie bylo to mozliwe ze wzgledu na zbyt duzy stopien
skomplikowania ukladu. Z czasem Intel pokazal, ze i architektura CISC
pozzwlala na takie rzeczy, czego dowodem jest 486, Pentium (tak naprawde
sa to dwa sklejone 486) czy PentiumPro, w ktorym zastosowano wiele
rozwiazan nie znanych jeszcze w konkurencyjnych ukladach RISC ;)).
Nawiasem mowiac, zaprezentowane juz przez Intela 433MHz procesorki nieco
podobne do PentiumPro okazuja sie byc bardzo mocna konkurencja chociazby
dla Alphy DEC'a. Jesli chodzi o porownanie np. 250MHz Alphy i 200MHz
PentiumPro to wcale nie bylbym pewien, ktory z tych ukladow wygra...
Jesli (teoretycznie) dorzucimy do tego mozliwosc korzystania z jednostki
MMX dostaniemy napewno mocno wydajniejsyz procesor po stronie Intela.
Zaden klasyczny RISC nie pozwala na tak szybkie przetwarzanie tego typu
danych w taki sposob.
Poza tym nie wiem w ogole po co ta dyskusja. Nie neguje wcale innych
procesorow. Powiem wiecej - sam uzywam nierzadko komputerow wyposazonych
w procesorki duzo lepsze niz Pentium. Jednak nadal widze miejsce na rynku
dla ukladow Intela i doceniam coraz wieksze mozliwosci jakie oferuja.
Doceniam tez cale masy oprogramowania jakie napisano na te procesorki.
Tego mi nie da zadna inna maszyna. Mozliwosci ukladow klasy PentiumPro
czy Pentium II chociazby, oraz nowinki typu MMX pozwalaja osiagac na
Intelach parametry osiagalne tylko na znacznie silniejszych maszynach. I
to tez jest budujace, ze zwykly, szary czlowiek, za zwykle, szare
pieniadze moze sobie na to pozwolic. Piszesz o wielkich kosztach Intela
(CISC) wynikajacych z historii i ograniczen, a chwile dalej piszesz, ze
Cie nie stac na alternatywe i musisz miec Intela... Przeczysz wiec sam
sobie. Jesli RISC bylby tanszy, to kto kupowalby przestarzalego Intela?
:))
>tyle moze przydlugiego wyjasnienia ile smiem rozumiec. Jesli urazilem
>czyjes uczucia religijne - przepraszam. I zapraszam na
>pl.soc.seks.fetish. pentium_MMX
Jesli to mialo byc zabawne, to musze przyznac, ze mamy bardzo odmienne
poczucie humoru (a takze dobrego smaku i kultury), prosze Szanownego Pana
Dariusza. Moze ja jestem chamem, a moze... :->>>
pozdrawiam,
karpio
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:00:44 MET DST