Autor: Maciej W. Rozycki (macro_at_ds2.pg.gda.pl)
Data: Thu 21 Feb 2002 - 13:49:36 MET
On Thu, 21 Feb 2002, Krzysztof Oledzki wrote:
> > 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
Tak i jeszcze: lbu, lhu, lwl, lwr, lwu, ld, ldl i ldr (cztery ostatnie to
MIPS64), jak juz szukamy roznorodnosci, jak widac wiekszej niz w x86,
ale...
> No i juz. rejestry masz co prawda 32 bitowe ale w niczym to
> nie przeszkadza. Jest ich sporo :)
... MIPS ma, ale Alpha -- juz nie zawsze. Wersje EV4 do EV5 nie mialy i
trzeba bylo maskowac "recznie" => dluzszy kod.
> > 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.
Ale dekoder obrabia tylko bity kodujace rozkaz -- reszta "leci"
bezposrednio na wewnetrzne magistrale adresowe albo danych, nie powodujac
komplikacji logiki dekodera.
> > 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)
Wlasnie o to. I tylko bity, ktore zaznaczyles jako "op" i "fc" sa
przetwarzane przez dekoder -- reszta to adresy lub argumenty
natychmiastowe, ktore sa kierowane odpowiednio. Innymi slowy, MIPS wcale
nie ma 2^32 rozkazow.
> 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? ;-)
Piec bajtow. Warunkowy -- szesc. Ale takie skoki (rowniez ze sladem)
wystepuja dosc rzadko. Zwykle zakres jest lokalny -- wtedy x86 oferuje
skoki dwubajtowe. A odlegle skoki zwykle realizuje sie w trybie adresacji
bezposredniej (tu dla x86 wystarcza jeden rozkaz -- max. siedem bajtow, a
w RISCu musisz ladowac rejestr -- dla MIPSa minimum dwa rozkazy, plus
nierzadko jeden cykl opoznienia na "load delay slot") albo rejestrowej
(dla x86 dwa bajty).
> > 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.
Tak? To dlaczego:
$ ls -la /usr/mipsel-linux/lib/libc-2.2.5.so
-rwxr-xr-x 1 root root 1631488 Feb 16 01:35 /usr/mipsel-linux/lib/libc-2.2.5.so
$ file /usr/mipsel-linux/lib/libc-2.2.5.so
/usr/mipsel-linux/lib/libc-2.2.5.so: ELF 32-bit LSB mips-1 shared object, MIPS R3000_LE [bfd bug], version 1 (SYSV), stripped
$ ls -la /lib/libc-2.2.5.so
-rwxr-xr-x 1 root root 1320356 Jan 24 13:18 /lib/libc-2.2.5.so
$ file /lib/libc-2.2.5.so
/lib/libc-2.2.5.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
???
> Wybrales najgorszy z mozliwych przypadkow :) Tak, to prawda
> tutuaj jest zle. :)))) Z tym ze w x86 jest jeszcze segmentacja...
Ktora i tak sie ogolnie ostatnio ignoruje.
> > 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.
Kara -- kara, ale jednak jest w stanie w kazdym takcie podeslac
instrukcje do dekodera. Kwestia odpowiedniego skomplikowania logiki.
> 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.
Przykre, ale cos za cos. Mniejszy kod w zamian za bardziej skomplikowane
przetwarzanie. Dokladnie jak w zalozeniach CISC.
> Tak bez rysunku ciezko jest to dokladnier wyjasniec
> ale chyba zasade zrozumiesz. Zeby sie za bardzie nie rozpisywac:
[...]
Jasne. Dzieki za opis. Ciekawa idea.
> > A jaka technologia ma teraz przyszlosc? Chyba nie powiesz, ze EPIC???
> Podobno CISC dekodowane na RISCe. :) Tak twierdza madrzy ludzie.
Znaczy sie rozwoj mikrokodu? No nie wiem... Juz chyba lepsze podejscie
to PALcode (ale Alpha to niestety trup).
> Aczkolwiek nie x86 CISC ktore ma zbyt duzo nalecialosci.
Niestety nie wiadomo jak dlugo rynek bedzie to kuriozum holubil...
> > 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.
Sa chyba jeszcze jakies stany posrednie pomiedzy "kazda", a "zadna".
Jakos nie przypominam sobie by ktos tu twierdzil, ze zlacza ISA maja byc
we wszystkich nowych plytach, a jedynie postulowal, by takie plyty w ogole
wystepowaly.
> Czyli _wiekszosc_ moze nie miec ISA. Ba lepije nawet zeby
> jej nie miala? No i OK. A czy jezeli ta osoba ktora _naprawde_,
Lepiej by te plyty, ktore nie maja zlacz ISA nie mialy tez pozostalosci
magistrali w postaci np. portow we/wy czy kontrolera dyskietek nie
mapowanych przez PCI, czy w ogole resztek PC/AT typu i8237 czy i8259.
> _naprawde_ potrzebuje zlacza ISA wyda te 800 zl wiecej (bo
> kupila karte i soft za 10k dolarow) to jest to wielka
> krzywda?
Nie przypuszczam. Zreszta mozna kupic sprzet uzywany -- jesli dobry
jakosciowo (inzyniersko) to starzeje sie diabelnie powoli.
-- + 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:52 MET DST