Autor: Maciej W. Rozycki (macro_at_ds2.pg.gda.pl)
Data: Thu 28 Feb 2002 - 17:59:24 MET
On Wed, 27 Feb 2002, Krzysztof Oledzki wrote:
> Hm.. troszke niezrecznie dalem Ci sie wmanewrowac w porownywanie RISC z
> CISC :) Ale na x86 CISC sie nie konczy. Zobacz jak to libc-2.2.5.so
> bedzie wygladac dla m68k :)
Hmm, chcialem byc sprawiedliwy i nie porownywac binariow dla i386 i
Alphy... ;-) A dla innych nie mam odpowiednich narzedzi.
Przypuszczam jednak, ze dla VAXa (inny klasyczny CISC) proporcje zostana
zachowane (z zastrzezeniem, ze trudno obecnie dla niego uzyskac
libc-2.2.5.so), a jezeli dla m68k nie, to albo kompilacja byla dokonana z
innymi opcjami, albo m68k ma wady zarowno architektury CISC (skomplikowane
przetwarzanie), jak i RISC (rzadki kod) bez zadnych zalet. Dziwne by to
bylo, ale nie znam m68k na tyle by sie wypowiadac.
> Ale, ale.. w RISCu masz baaaaaaaardzo duza szanse ze w kazdym takcie zostanie
> wykonana jedna instrukcja. A w CISC nie masz w ogole o czym marzyc.
Tak, a w dodatku typowo sa dostepne rozkazy trojargumentowe, ktore
nierzadko znacznie przyspieszaja operacje ALU.
> Jak chcesz to moge cos wiecej wygrzebac. Idea bardzo ciekawa i
Mam gdzies specyfikacje SPARC -- jak bede chcial znac szczegoly, to sobie
poczytam. Poki co nie mam czasu ani odpowiedniego sprzetu na horyzoncie,
by sie w to wglebiac.
> jak sie na to patrzy dosc oczywista. :) Jak to sie stalo
> ze nikt wczesniej na to nie wpadl?
Mysle, ze mogly tu miec wplyw dwa czynniki warunkujace takie rozwiazanie:
1. Doswiadczenie oparte na innych istniejacych implementacjach.
2. Przekonanie o zysku na wydajnosci uzyskanym kosztem usztywnienia ABI.
> Chodzi o to zeby z pamieci trzeba bylo przeslac jak najmniej danych
> (co jest domena CISCow - jak sie patrzy na takie instrukcje
> jak enter i leave dla x86) ale zeby byly sprawnie i szybko wykonywane
> (co jest zapewniane w RISC).
Niby racja -- wracaja problemy, ktore zainicjowaly rozwoj architektury
CISC, tylko w nieco innym aspekcie -- juz nie wysoka cena, a
niedostateczna przepustowosc pamieci powoduje koniecznosc zwiekszenia
gestosci kodu. Tyle ze cena za to jest wzrost poziomu skomplikowania
procesora, a wiec kosztu jego produkcji i wydzielanej mocy, co jest
niejako zaprzeczeniem niektorych podstaw architektury RISC i powoduje
nieprzydatnosc takich rozwiazan w wielu zastosowaniach. Czas pokaze, jak
sie sytuacja rozwinie.
> > 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.
> A tak, tak. I zeby jeszcze zrobic cos z IDE (po co mu az 2 przerwania?),
To jest bardziej problem programowy, niz sprzetowy -- w przypadku
rozwiazan integrowanych w chipset'cie (np. rodzina Intel PIIX) jedynie
niechlujstwem projektantow mozna wytlumaczyc niemapowanie przerwan ATA w
przestrzeni PCI. Choc oczywiscie uzycie osobnych przerwan (w miare
dostepnych zasobow) dla poszczegolnych urzadzen owocuje nieco szybsza ich
obsluga.
> nieszczesnym dzieleniem przerwan w PCI, zajmowaniem jednego przerwania
To tez bardziej problem inzynierski niz projektowy -- nikt nikomu nie
broni przerwan A - D z poszczegolnych magistral kierowac do roznych wejsc
ukladow I/O APIC.
> przez koprocesor, itd itp... :))
To juz przeszlosc -- linia bledu FPU nie jest podlaczana do I/O APIC i
raczej to kuriozum zniknie wraz z i8259.
-- + 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:21:18 MET DST