Autor: Maciej W. Rozycki (macro_at_ds2.pg.gda.pl)
Data: Wed 20 Feb 2002 - 18:01:55 MET
On Tue, 19 Feb 2002, Krzysztof Oledzki wrote:
> > Wybacz, ale linia x86 nie jest zgodna nawet z 8080, nie mowiac juz o
> > starszych rozwiazaniach. Jedyna spuscizna po wczesniejszych rozwiazaniach
> > sa rozkazy "lahf" i "sahf", ktore jedynie ulatwiaja przenoszenie
> > oprogramowania z 8080 (ten drugi, zreszta, polecany jest ostatnio przez
> > producenta jako optymalny sposob testowania statusu jednostki
> > zmiennoprzecinkowej).
> Hm.. moze tak: 1-1 oczywiscie nie. Ale czy nie masz tych samych rejestrow?
> A, B, C? Oczywiscie ze masz - i to nawet w kilku wersjach - AH, AL, EAX...
Nie -- 8080 mial 8-bitowe rejestry A (akumulator), B, C, D i E
(pomocnicze) oraz H i L (adresowe). Pewne rozkazy umozliwialy uzycie
rejestrow B - L jako par 16-bitowych, w szczegolnosci pary H i L.
Operacje ALU byly mozliwe prawie wylacznie na rejestrze A.
> Czyli zamiast 1 reejstru masz trzy - jak widac dzieki temu jest
> 3 razy wiecej instrukcji, ktore sa powiazane z tymi rejestrami.
I? Jakos rejestry trzeba adresowac, chyba ze masz tylko jeden. W tym
przypadku mozesz uznac, ze masz po prostu 24 rejestry do zaadresowania --
nic szczegolnego np. Alpha ma 32. I cos za cos -- mozesz wykonywac
operacje na porcjach o rozmiarze ponizej slowa, np. na bajtach, co nie
kazdy procesor potrafi.
> > Te "niepotrzebne" mozna policzyc na palcach rak. Mam wymienic? Znaczna
> > czesc z tych kilkuset instrukcji to calkiem nowe wymysly typu MMX i SSE.
> Hm.. Ty patrzysz na instrukcjie jako np. na MOV AX, BX. A ja patrze
> jak na pelna kombinacje bitow - i tak MOV AX, WORD PTR ES:SI to jest
> zupelnie cos innego niz MOV BX, WORD PTR ES:SI. Inaczej sie koduje i procesor
Liczy sie ile bitow stanowi kod rozkazu ("opcode") -- reszta to
argumenty. Np. w powyzszych kod rozkazu to 8 bitow. Prefix mozna uznac
za argument.
> wykonuje to w zupelnie innej ilosci taktow zegara. A przynajmniej do niedwana
> tak robil - obecnie nie wiem jak to wyglada zdekodowane na RISCE.
Typowo cala instrukcja (wraz z argumentami) ma stala dlugosc 32 bitow
(rowniez dla procesorow 64-bitowych), zas liczba formatow rozkazow jest
ograniczona. Np. MIPS ma trzy formaty rozkazow, z ktorych dwa koduja
rozkaz na szesciu bitach, zas trzeci -- na dwunastu.
> > Cache nie ma nic do rzeczy -- i tak jest u rodziny x86 wyjatkowo maly.
> > Zas skomplikowane rozkazy realizuje mikrokod, ktory nie jest specjalnie
> > obszerny.
> Ma zanaczenie - jezeli na zakodowanie jednej instrukcji tzreba dwa razy
> wiecej bajtow to cache takze musi byc dwa razy wiekszy zeby sie w nim
> tyle samo kodu zmiescilo.
Ale kod x86 jest wyjatkowo gesty -- na zakodowanie tych samych operacji
potrzeba wyjatkowo malo rozkazow w porownaniu do innych procesorow (to
zreszta cecha charakterystyczna procesorow CISC -- w koncu takie jest ich
zalozenie).
Np. wpisanie stalej "0xfedcba98" do pamieci pod adres "0x76543210" dla
procesora i386:
movl $0xfedcba98,0x76543210 # 10 bajtow -- wyjatkowo dluga instrukcja
dla procesora MIPS:
lui $8,0xfedc
ori $8,$8,0xba98
lui $1,0x7654
sw $8,0x3210($8) # 4 * 4 bajty = 16 bajtow
Nawet gdy rownowazne operacje daja sie zakodowac ta sama liczba
instrukcji, sa one zwykle krotsze dla i386, np. miedzyrejestrowe rozkazy
ALU to tylko dwa bajty, a inkrementacja/dekrementacja -- to jeden.
> > Tak, a np. dla procesorow Alpha, MIPS czy SPARC -- dwa do trzech razy
> > wiecej. Czy to znaczy, ze sa one przestarzale? Czy po prostu pamieci
> > stanialy?
> No chyba na oczy nie widziales RISCOW. Tam zeczywiscie trzeba wiecej
> instrukcji ale _kazda_ z nich zajmuje dokladnie 4 bajty. 1 slowo.
> Nie ma dublujacych sie instrukcji i nie ma podzialu na rejestry.
Zebys sie nie zdziwil. Nawet potrafia byc rejestry dedykowane i rozkazy
na nich operujace.
> No i pomyslu Sparca z przelaczaniem okien rejestrow nic nie jest
> w stanie pobic.
Ciekawe -- mogbys nieco przyblizyc?
> Zreszta porownanie do RISCOW jest troszke niezreczne bo juz od
> dawna wiadomo ze ta technologia nie ma przyszlosci - jak kazda miala swoj czas
> swietnosci ale teraz wiadomo ze byla to wyczieczka w slepa uliczke.
> Aczkolwiek wniosla ono sporo :)
A jaka technologia ma teraz przyszlosc? Chyba nie powiesz, ze EPIC???
> Z tym ze jakos nikt nie krzyczy ze chce miec 100 razy
> wydajniejszy sprzet na takie archaiczne systemy. Nie krzyczy
> bo widomo ze nie ma to sensu.
Raczej chodzi o to, ze w starym jakas istotna czesc ulegla uszkodzeniu i
jest klopot z uzyskaniem nowej, zgodnej z reszta systemu.
> Kosztuje kilkaset dolarow i juz. Jest twoja. Tylko po co
> mi w nowej plycie glowiej ISA skoro nigdy tam nie wloze zadnej karty?
> Po to zeby jedna osoba na tysiac umiescila tam stara karte
> pomiarowa?
Chocby po to. Z prostego rachunku wynika, ze jedna plyta na tysiac
powinna miec zlacze ISA.
> > Ktos Ci broni skonstruowac odpowiedni most? Na pewno nie standard PCI --
> > jest otwarty.
> Nikt nie broni. Z tym ze najzwyczajniej w swiecie nie jest mi to potrzebne :)
> I o to chodzilo - PC nigdy nie bedzie i nie moze byc komputerem
> idelanie uniwersalnym.
Wlasnie jest uniwersalny -- mimo wielu obrzydliwych rozwiazan, jest to
badz co badz system otwarty i kazdy moze zaprojektowac i skonstruowac
odpowiednie urzadzenie wspolpracujace i napisac da niego oprogramowanie.
W przypadku innych systemow bywa to klopotliwe ze wzgledu na brak
specyfikacji.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro_at_ds2.pg.gda.pl, PGP key available +
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 00:18:40 MET DST