Autor: Krzysztof Oledzki (ole_at_WytnijTo.hoth.jmg.com.WytnijTo.pl)
Data: Thu 21 Feb 2002 - 11:53:51 MET
Maciej W. Rozycki <macro_at_ds2.pg.gda.pl> wrote:
> On Tue, 19 Feb 2002, Krzysztof Oledzki wrote:
>> 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.
Wszystkie RISCE ktore widziale znam maja 32. Z tym ze sa to
_dokladnie_ 32 rejestry. W instrukcji na zapis rejestru
przwidziane jest 5 bitow.
> I cos za cos -- mozesz wykonywac
> operacje na porcjach o rozmiarze ponizej slowa, np. na bajtach, co nie
> kazdy procesor potrafi.
I nie musi potrafic. SKoro juz mowimy o MIPSIE, masz np instrukcjie
lw - load word - 32 bity
lh - load half-word - 16 bitow
lb - load byte - 8 bitow
No i juz. rejestry masz co prawda 32 bitowe ale w niczym to
nie przeszkadza. Jest ich sporo :)
>> > 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.
A ja sie bede upierac ze opcode,prefix itd jest czescia instrukcji. Procesor
musi pobrac z pamieci calosc zeby to potem wykonac. Trzeba wiec to
przeslac z pamieci, zdekodowac. To trwa. No i zajmuje to dana ilosc
miejsca w pamieci.
>> 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
Takie jest zaloznie RISCow. Dzieki temu bez kombinowania mozna
potokowao przetwarzac instrukcjie bo dokladnie wiadomo gdzie zaczyna
sie nastepna i nastepna i nastepna i...
> (rowniez dla procesorow 64-bitowych), zas liczba formatow rozkazow jest
> ograniczona.
Dokladnie.
> Np. MIPS ma trzy formaty rozkazow, z ktorych dwa koduja
> rozkaz na szesciu bitach, zas trzeci -- na dwunastu.
Hm... zaraz zaraz... Chodzi o cos takiego?
1) op(6bit)+rs(5bit)+rt(5bit)+rd(5bit)+sh(5bit)+fc(6bit)
2) op(6bit)+rs(5bit)+rt(5bit)+ad/iv(16bit)
3) skok bezwarunkowy: op(6bit)+ta(26bit)
Ale musialbym zerknac do dokumentacji :))
Z tym ze wcale tak nie musi byc - w sparcu np. na skok bezwarunkowy
masz 2 bitowa instrukcje + 30 bitow na adres dzieki czemu mozna skakac
pod dolny adres z 4 GB (bo kazda instrukcja rozpoczyna sie
co 4 bajty!). Ile taki skok bedzie zajmowal w x86? ;-)
>> > 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).
Hm.. to prawda tylko ze pamietaj iz takich instrukcji, na ktorych
zapisanie w riscach trzeba wiecej pamieci, w przecietnym programie
jest kilka procent.
> 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
Wybrales najgorszy z mozliwych przypadkow :) Tak, to prawda
tutuaj jest zle. :)))) Z tym ze w x86 jest jeszcze segmentacja...
> 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.
No wlasnie. To teraz pomsyl sobie jaka to jest kara dla jednostki
potoku ktora odpowiada za ladowanie nastepnej instrukcji.
Gdzie do <....> bedza zaczynac sie nastepne 3 instrukcje? Ano
do czasu ich zdekodowania nie wiadomo. A jak wiesz,
w obecnych procesorach wszytsko jest wykonowane potokowo.
AFAIK w p4 caly potok sklada sie z ponad 20 etapow. A wiec
w danym momencie jest przetwrzane ponad 20 instrukcji.
>> > 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.
Nie dziwie sie.
>> No i pomyslu Sparca z przelaczaniem okien rejestrow nic nie jest
>> w stanie pobic.
> Ciekawe -- mogbys nieco przyblizyc?
Tak bez rysunku ciezko jest to dokladnier wyjasniec
ale chyba zasade zrozumiesz. Zeby sie za bardzie nie rozpisywac:
Jak wiesz, wywowalnie procedury wiaze sie z koniecznoscia
zapisania na stosie adresu powrotu, zmodyfikowania
okna i wskaznika stosu, odloznie na stosie
argumentow, zapamietaniu modyfikowanych
rejestrow (bo czesc po powrocie z procedura ma
obowiazek byc nieruszona), itd itp. Jak wiadomo
dostep do pamieci (gdzie jest stos) jest dosc powolny -
duuuuuzo wolniejszy niz dostep do rejestrow. W Sparcu
wymyslili wiec sobie ze procesor ma, owszem z punktu
wiedzenia danego kodu 32 rejestry ale tak na prawde
ma ich sporo wiecej. W przypadku wywlania procedury
nastepuje "przelacznie okien" - nowe okno zawiera
wlasne rejestry tymczasowe - 8, rejestry ktore poprzednio
zawieraly argumenty do wywloania teraz zawieraja agrumenty
z wywolania - 8, 8 rejestrow na agrumenty do wywalonia
(ewetualnego) nastepnej procesury znowu nakladaja
sie z nastepnym oknem, a 8 rejestorow nigdy sie nie zmienia.
90% procedur nie posiada wiecej niz 7 argumentow, ktore
nie mieszcza sie na 32 bitach. Dla pozostalych 10% trzeba
znowu pobawic sie stosem ale "kara" za to nie jest
zbyt duza wiec sie baaardzo cos takiego oplaca.
>> 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???
Podobno CISC dekodowane na RISCe. :) Tak twierdza madrzy ludzie.
Aczkolwiek nie x86 CISC ktore ma zbyt duzo nalecialosci.
>> 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.
Czyli przyznajesz ze _nie kazda_ plyta musi mieci ISA.
Czyli _wiekszosc_ moze nie miec ISA. Ba lepije nawet zeby
jej nie miala? No i OK. A czy jezeli ta osoba ktora _naprawde_,
_naprawde_ potrzebuje zlacza ISA wyda te 800 zl wiecej (bo
kupila karte i soft za 10k dolarow) to jest to wielka
krzywda?
Pozdrawiam,
Krzysztof Oledzki
-- Krzysztof Oledzki e-mail address: ole(at)ans.pl Linux Registered User: 189200 Internic NickHandle: KO581
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 00:18:49 MET DST