Dlaczego ktokolwiek miałby chcieć CISC?

W naszym wykładzie dotyczącym systemów komputerowych zapoznaliśmy się z procesorem MIPS. Został (ponownie) opracowany w trakcie tego okresu i faktycznie był dość łatwy do zrozumienia. Wykorzystuje projekt RISC , co oznacza, że ​​jego podstawowe polecenia są regularnie kodowane, a jest ich niewiele, aby uprościć przewody.

Wspomniano, że CISC kieruje się inną filozofią. Spojrzałem krótko na zestaw instrukcji x86 i byłem zszokowany. Nie mogę sobie wyobrazić, jak ktoś chciałby zbudować procesor, który używa tak złożonego zestawu poleceń!

Sądzę więc, że muszą istnieć dobre argumenty, dlaczego duża część rynku procesorów korzysta z architektur CISC. Czym oni są?

Istnieje ogólny trend historyczny.

W dawnych czasach wspomnienia były małe, a więc programy były bardzo małe. Ponadto kompilatory nie były zbyt inteligentne, a wiele programów napisano w asemblerze, dlatego dobrze było móc napisać program przy użyciu kilku instrukcji. Rurociągi instrukcji były proste, a procesory pobierały jedną instrukcję na raz, aby ją wykonać. Maszyny wewnątrz procesora i tak były dość skomplikowane; instrukcje dekodowania nie były uważane za duże obciążenie.

W latach 70. projektanci procesorów i kompilatorów zdali sobie sprawę, że tak złożone instrukcje wcale nie były tak pomocne. Trudno było zaprojektować procesory, w których te instrukcje były naprawdę wydajne, i trudno było zaprojektować kompilatory, które naprawdę skorzystały z tych instrukcji. Obszar chipów i złożoność kompilatora lepiej wydano na bardziej ogólne zadania, takie jak rejestry ogólnego przeznaczenia. Artykuł Wikipedii na temat RISC wyjaśnia to bardziej szczegółowo.

MIPS to najlepsza architektura RISC i dlatego jest tak często uczona.

Rodzina x86 jest nieco inna. Pierwotnie była to architektura CISC przeznaczona dla systemów z bardzo małą pamięcią (nie ma miejsca na duże instrukcje) i przeszła wiele kolejnych wersji. Dzisiejszy zestaw instrukcji x86 jest nie tylko skomplikowany, ponieważ jest to CISC, ale ponieważ tak naprawdę jest 8088 z 80386 z Pentium, być może z procesorem x86_64.

W dzisiejszym świecie RISC i CISC nie są już czarno-białym wyróżnieniem, jakim mogły być kiedyś. Większość architektur procesora ewoluowała do różnych odcieni szarości.

Po stronie RISC niektóre nowoczesne warianty MIPS dodały instrukcje mnożenia i dzielenia, z niejednolitym kodowaniem. Procesory ARM stały się bardziej złożone: wiele z nich ma 16-bitowy zestaw instrukcji o nazwie Thumb oprócz „oryginalnych” 32-bitowych instrukcji, nie mówiąc już o Jazelle do wykonywania instrukcji JVM na CPU. Nowoczesne procesory ARM mają również instrukcje SIMD do aplikacji multimedialnych: w końcu niektóre złożone instrukcje są opłacalne.

Po stronie CISC wszystkie najnowsze procesory są w pewnym stopniu wewnątrz RISC. Mają mikrokod, aby zdefiniować wszystkie te złożone instrukcje makr. Sama złożoność procesora sprawia, że ​​projektowanie każdego modelu zajmuje kilka lat, nawet w przypadku projektu RISC, co w przypadku dużej liczby komponentów, z potokami i przewidywalnym wykonaniem i tak dalej.

Dlaczego więc najszybsze procesory pozostają na zewnątrz CISC? Część tego, w przypadku rodziny x86 (32-bitowej i 64-bitowej), to zgodność historyczna. Ale to nie wszystko. Na początku XXI wieku Intel próbował przeforsować architekturę Itanium . Itanium jest ekstremalnym przypadkiem skomplikowanych instrukcji (jednak nie tak naprawdę CISC: jego konstrukcja została nazwana EPIC ). Pozbywa się nawet staromodnego pomysłu wykonywania instrukcji po kolei: wszystkie instrukcje są wykonywane równolegle, aż do następnej bariery. Jednym z powodów, dla których Itanium nie wziął, jest to, że nikt, czy to w Intelu, czy gdzie indziej, nie mógłby napisać dla niego porządnego kompilatora. Teraz rozumiemy już stary, dobry, w większości sekwencyjny procesor, taki jak x86_64.

Zestaw instrukcji x86 jest trochę specjalnym przypadkiem. Myślę, że Motorola 68K i DEC VAX są nieco lepszymi przykładami CISC. W czasach dużej ilości kodu asemblerowego ludzie myśleli, że bardzo regularny, bardzo inkluzywny ISA jest lepszy: wierzę, że nazwali różnicę między kodem asemblera a sposobem, w jaki ludzie myśleli „ luką semantyczną ”. Teoretycznie chciałeś zestaw instrukcji, który pasowałby do twojego sposobu myślenia.

Innym dużym sterownikiem projektowym dla CISC wydaje się być „ortogonalność”: każda instrukcja działałaby z każdym trybem adresowania (rejestr, adres bezwzględny, względne przesunięcie itp.). Możesz zobaczyć, jak bogey ortogonalności pojawia się w projektowaniu API w Distributed Computing Environment (DCE) i w CORBA. Ten pomysł nie ogranicza się do projektowania zestawu instrukcji.

Jednym z powodów CISC było gęste kodowanie instrukcji (pamięć była droga). Cały pomysł RISC polegał na przyspieszeniu procesora poprzez ciągłe pobieranie instrukcji o tym samym rozmiarze (bez skomplikowanego, wolnego kroku „określ rozmiar instrukcji”), aby robili proste rzeczy (więc szybko jest dowiedzieć się, co zrobić) . Pamięć była tania. Ten uwolniony obszar obwodów w CPU dla innych rzeczy (więcej rejestrów, więcej jednostek przetwarzających, więc kilka instrukcji można wykonać równolegle, jeśli są one niezależne). Ponieważ procesor był znacznie wolniejszy niż pamięć RAM, opłacało się to. Ale procesory przyspieszyły (i zrobiły więcej równolegle i ...), podczas gdy pamięć RAM nie przyspieszyła (przynajmniej nie w takim samym tempie, jak zużycie danych przez procesor ze względu na zwiększoną równoległość). Poznaj pamięć podręczną, szybką jak procesor, ale niewielką. Teraz pamięć znów jest na wagę złota, nie ze względu na koszty, ale ze względu na szybkość. Czas odnowienia CISC. Tymczasem procesory stały się bardziej złożone, do tego stopnia, że ​​dzisiejszy mikroprocesor robi wiele z tego, co zrobił kompilator RISC: Podział operacji na elementarne części, zmiana kolejności wewnętrznych instrukcji RISCy, aby można je było wykonywać jednocześnie, gdy tylko jest to możliwe. RISC został źle opisany jako „Zwolnij ważne rzeczy dla kompilatora” z jakiegoś powodu ...

Prawdziwą zaletą CISC jest zmniejszenie pamięci i presji pamięci podręcznej, a to samo czyni go lepszym w wymagających aplikacjach o wysokiej wydajności, ponieważ głównym wąskim gardłem w takich systemach jest przepustowość pamięci. Biorąc pod uwagę pamięć podręczną o jednakowej wielkości, procesory CISC mogą opisywać więcej informacji niż RISC. Ponadto, ponieważ instrukcje CISC wiążą się z kilkoma mikrooperacjami, może być możliwe ulepszenie architektury, które może zapewnić najszybszą ścieżkę wykonania dla tej instrukcji, jaką mogłoby kiedykolwiek napisać pojedyncze instrukcje. Krótko mówiąc, procesory CISC są bardziej wydajne w wykorzystaniu przepustowości pamięci, co często przekłada się na wzrost wydajności w zastosowaniach wymagających dużej ilości pamięci.

Na przykład, aby wykonać R1 = R2 + R3 + R4 + R5 + R6i wypchnąć wynik na stos, powiedzmy, że kod RISC jest zapisany jako,

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

i jako taki wymaga 16 bajtów miejsca.

W CISC, ze względu na możliwość różnych stylów kodowania, te same informacje można przedstawić w następujący sposób ...

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

który zajmuje tylko 12 bajtów pamięci. W ten sposób poprawiono wykorzystanie pamięci, pozwalając procesorowi zobaczyć więcej instrukcji, a tym samym skrócić bezczynne cykle.

Ważnym aspektem, o którym nikt nie wspomniał, jest to, że prawie wszystkie procesory CISC są architekturami mikrokodowanymi. Mikrosekwenator i sklep kontrolny zajmują znacznie mniej nieruchomości niż kontroler przewodowy, a zestaw instrukcji można modyfikować bez modyfikowania sprzętu.

Mikroprocesory były nowymi urządzeniami, kiedy wszedłem na pole. Bardzo popularną praktyką w latach siedemdziesiątych i wczesnych osiemdziesiątych było składanie procesora za pomocą jednostek ALU bit-slice, jednostki sterującej opartej na mikrosekwenserze oraz magazynu sterowania, w którym ładowano lub wdmuchiwano zestaw instrukcji mikrokodowanych. Komputery te były oparte na logice tranzystorowo-tranzystorowej serii 7400 (TTL). 4-bitowa jednostka ALU 78181 została wykorzystana do zbudowania wielu procesorów, w tym DEC PDP-11 i wczesnych komputerów VAX 11, Data General Nova, Xerox Alto i komputera stacjonarnego Wang.

Trudno będzie znaleźć komputer, który nie korzysta z procesora zgodnego z x86. Ten zestaw instrukcji pokonał MIPS, pokonał Sparca, pokonał Alfę, pokonał Titanica (mogłem przeliterować to imię). Z drugiej strony MIPS już prawie nie istnieje. Bez względu na to, co dziś myślisz, bardzo sprytni ludzie myśleli, że zestaw instrukcji x86 był naprawdę dobrym pomysłem i zarobili na tym mnóstwo pieniędzy.

Komputery zaczęły jako RISC, ponieważ złożony zestaw instrukcji był tuż poza możliwościami implementatorów. Jeśli chcesz zobaczyć zestaw instrukcji RISC, spójrz na zestaw instrukcji CDC 6400-6600 i CDC Cyber ​​170-175. To jest właściwe RISC. Około 10 lat temu zapytałem niektórych projektantów układów, ile zajmie miejsca (w rogu rozsądnego zaawansowanego układu GPU). Powiedzieli mi o 1 mm2 - w tym pamięci RAM maszyny, która zajmie 99% tego miejsca.

Kiedy ludzie mogli budować maszyny CISC, mieli przewagę. Pamiętaj, że x86 został wydany na długo przed MIPS, 1978 vs. 1985. W tym czasie potrzebowałeś cykli procesora do czytania instrukcji, dekodowania ich, wykonywania. MIPS w 1978 r. Zająłby cztery cykle na instrukcję i na operację. Jeśli weźmiesz instrukcję x86, taką jak „dodaj rejestr do pamięci”, zajmie to może 7 cykli dla instrukcji, ale wykonasz 3 operacje. To była duża zaleta. Im więcej masz różnych instrukcji i im mocniejsza jest każda instrukcja, tym większa przewaga.

A kiedy opracowano 64-bitowy zestaw instrukcji x86 z jego koszmarnymi kodami prefiksów, złożoność zestawu instrukcji nie miała już znaczenia. Obecnie CISC jest właśnie tłumaczony na RISC, a cały biznes tłumaczeniowy może być jednym procentem chipa.

To pytanie ma wiele wspólnego z najnowszymi trendami w informatyce, które sprzyjają masowemu przejściu na komputery przenośne i tablety, tym samym faworyzując procesor RISC, i złapały Intela (prawdopodobnie największego na świecie dostawcę CISC) w niekorzystnej sytuacji w tak zwanym „fleksji” point ” dokładnie tak, jak Grove zwracał uwagę i ostrzegał przed nim. Krótka historia polega na tym, że CISC wydaje się rozpływać w obliczu ogromnego ataku na mobilne obliczenia zmieniającego paradygmat / zmieniającego gamę ze względu na jego z natury wysokie zużycie energii.

CISC prawdopodobnie będzie zawsze dostępny na komputerze, ale mobilność jest powszechnie uważana za nową przyszłość komputerów. Wiele krajów rozwijających się (z dużymi potencjalnymi populacjami komputerowymi) faktycznie w dużej mierze pominie fazę pulpitu. Zobacz na przykład wzrost i spadek komputerów stacjonarnych

Doskonałym studium przypadku tego pytania jest poczytać o Mike'u Bellu, który pracuje dla Intela na nowej pozycji, próbując lepiej pozycjonować Intela na rynku mobilnym poprzez procesor Atom za pośrednictwem projektu / inicjatywy podobnej do „skunkworks”, z bardzo silnym zarządem wsparcie. Rynek mobilny jest ściśle powiązany z architekturą RISC, a głównie procesorami ARM, głównie ze względu na ich wysoką efektywność energetyczną (zużycie energii), nowe kluczowe kryteria obliczeniowe, o których wspomina pytanie i nie ma innych odpowiedzi. Oto dwa najnowsze artykuły, które ukazują wiele z wewnętrznego myślenia korporacyjnego (i wynikającej z tego sprzeczności!) Na ten temat:

• Intel odrzuca „podatek x86”, nie widzi przyszłości dla ARM ani żadnego z jego konkurentów

• Imperium kontratakuje: Intel Muscles na rynek mobilny

Czynnikiem nie wymienionym w innych odpowiedziach jest ekonomiczny. Chodzi również o Intel. Architektura CISC jest w dużej mierze reprezentowana przez rodziny x86 i x64. Wszystkie pochodzą od skromnego 8088 zastosowanego w oryginalnym komputerze IBM. Wczesna dominacja rynkowa tej serii komputerów oznaczała, że ​​Intel miał solidny strumień przychodów na badania i rozwój. W połączeniu z faktem, że Intel był w stanie ograniczyć konkurencję poprzez odstąpienie od / anulowanie swoich umów drugiego źródła, oznaczało, że ceny procesorów mogą wzrosnąć do ekstremalnych poziomów, zapewniając bardzo bogatą marżę zysku brutto.

Tak więc, podczas gdy inni producenci procesorów starali się dotrzymać kroku, Intel był w stanie wydać miliardy dolarów na opracowanie nowszych, szybszych produktów. Konkurs RISC nie mógł wydać prawie tyle pieniędzy. Wiele procesorów RISC zniknęło z rynku. Gdzieś:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, POWER (do użytku z komputerem), Hitachi SuperH ...

Pamiętam ekspertów z tamtej epoki, którzy ogłosili, że wojna RISC kontra CISC zakończyła się i CISC wygrał. Nie było. Po prostu wyprzedził wszystkich.

Czy ta dynamika może się kiedykolwiek zmienić? Już jest. Żadna korzyść ekonomiczna nie jest absolutna.

Piętą achillesową x86 jest żarłoczny apetyt na moc. To pozwoliło mniejszemu, zwinniejszemu konkurentowi (ARM) rozwijać się na rynkach (takich jak telefony / tablety itp.), Na których oszczędzanie energii miało znaczenie.

Świetnym filmem na ten temat od członka zespołu ARM jest procesor ARM - Sowing the Seeds of Success - Computerphile około 8:30

Drugim problemem dla x86 jest sukces strategii Intela. Udało im się wyeliminować prawie całą konkurencję. Zwolnili. Od lat nowe procesory Intel zapewniają tylko bardzo skromne ulepszenia. Co gorsza, super bogate marże to trudna dieta, którą można zrezygnować z każdej korporacji.

Dzisiaj systemy oparte na procesorach ARM (SOC) i konkurencyjne układy x64 AMD, znów sprawiają, że rynek procesorów jest interesującym miejscem. (MOIM ZDANIEM)

Istnieje wiele powodów, dla których warto wybrać wdrożenie CISC. Najważniejszym powodem jest zgodność binarna z istniejącym zestawem instrukcji CISC. Podczas gdy oprogramowanie do tłumaczenia binarnego oprogramowania uległo poprawie, kompatybilność sprzętowa ma pewne zalety techniczne (a także wadę mniejszego buforowania tłumaczeń) i mniejszą zaletę techniczną polegającą na tym, że wydaje się bardziej niezawodna.

Gęstość kodu jest prawdopodobnie drugim najważniejszym powodem wyboru CISC. Renesas RX został zaprojektowany jako CISC specjalnie pod kątem gęstości kodu, ponieważ jest przeznaczony dla mikrokontrolerów, w których rozmiar pamięci kodu jest znaczącym czynnikiem kosztowym. Instrukcje o zmiennej długości, instrukcje złożone (głównie więcej trybów adresowania), niejawne operandy i niższy rejestr liczą wszystkie gęstości kodu korzyści.

Historycznym (i moim zdaniem błędnym) powodem wyboru CISC było zlikwidowanie semantycznej luki między programistami używającymi języka wyższego poziomu a procesorem. Ponieważ złożone instrukcje można ogólnie zastąpić sekwencją prostszych instrukcji, złożoność kompilatora języka wyższego poziomu dla RISC nie musi być znacznie bardziej złożona niż dla CISC dopasowanego do języka. RISC unika „kolizji semantycznej” (gdy instrukcja procesora działa mniej więcej niż odpowiednia instrukcja języka) i ułatwia redukcję siły i optymalizację planowania. (Aby uzyskać więcej szczegółów, zobacz „Jakie są kompromisy w pracach rozwojowych kompilatora nad CISC vs. RISC?” ).

Wykonywanie instrukcji może wiązać się ze znacznymi kosztami stałymi. Zachęca to do stosowania stosunkowo skomplikowanych instrukcji w celu rozłożenia tego obciążenia na bardziej rzeczywistą pracę; zmniejszenie liczby instrukcji dynamicznych może poprawić wydajność. Kiedy koszt logiki i pamięci RAM był znacznie większy niż koszt pamięci ROM, zachęta do wykonywania złożonych instrukcji była znacząca, ponieważ instrukcja została zdekodowana przez wyszukanie mikrokodu.

Powodem użycia CISC, któremu być może zaprzeczają dowody historyczne, jest fakt, że mikrokod może być zoptymalizowany dla każdej mikroarchitektury, podczas gdy standardowe biblioteki mogą powoli wykorzystywać funkcje nowej implementacji. Poziom optymalizacji implementacji oprogramowania memcopy w porównaniu z poziomem mikrokodu dla REP MOVSB ​​oznacza, że ​​biblioteki mogą zwrócić większą uwagę niż mikrokod. Część tego może pochodzić od dostawcy procesora ukierunkowanego na szerszą bazę użytkowników, więc uzasadnienie wysiłku może być trudniejsze w porównaniu z oprogramowaniem open source lub wewnętrznym, w którym zlokalizowane zainteresowania deweloperów lub użytkowników mogą wpływać na wysiłki związane z wdrożeniem.

Możliwość dostarczenia zoptymalizowanej biblioteki standardowej z procesorem ma znaczące zalety. Przechowywanie i wykonywanie standardowej biblioteki platformy można znacznie zoptymalizować dzięki oprogramowaniu sprzętowemu. Różnica między złożoną instrukcją a wywołaniem warstwy abstrakcji platformy może być subtelna (lub nieistniejąca). Projekt RISC mógłby wykorzystywać te same techniki implementacji do obsługi wywołań PAL, jak CISC w przypadku złożonych instrukcji, w tym za pomocą operacji nie dostarczonych w ogólnym zestawie instrukcji ze specjalistycznym sprzętem, używając sprytnego buforowania i dekodowania oraz określania operandów rejestru (chociaż CISC często używają dedykowanych rejestrów podobnych do ABI dla każdej funkcji). Model mentalny związany z CISC może zachęcać do takich optymalizacji. Ponadto użytkownicy mogą być mniej obrażeni przez wymuszone włączenie „

Dekodowanie stosunkowo skomplikowanych instrukcji może mieć mniejszy narzut (i być może bardziej niezawodnie poprawne w dostrzeganiu intencji) niż porównywalna technika rozpoznawania idiomu RISC, w której sekwencja instrukcji jest rozpoznawana jako jednostka semantyczna. Ta różnica narzutu byłaby najbardziej zauważalna w mniejszej implementacji, ale narzut związany z wykorzystaniem tych informacji zmniejsza znaczenie oszczędności na dekodowaniu.

Dodatkowe informacje kontekstowe mogą ułatwić optymalizację sprzętu. Na przykład podczas zwiększania wartości w pamięci sprzęt może rozpoznać, że adres pamięci jest używany dwukrotnie (dla obciążenia i magazynu), co daje możliwość zapamiętywania w pamięci podręcznej i buforowania translacji. Złożone instrukcje mogą zawierać takie informacje w sposób jawny. W instrukcji złożonej wartości pośrednie mają jawny czas życia (czas trwania instrukcji); z tradycyjnym rejestrem RISC wartości muszą zostać wyraźnie nadpisane, aby wskazać koniec ożywienia. (Uwaga: RISC może określić rejestr, który jest zawsze zerowany po każdym użyciu, zapewniając sposób na określenie wartości tymczasowej jednorazowego użytku. Takie instrukcje byłyby umiarkowanie bardziej złożone).

Jeśli szczegóły implementacji nie są ukryte za warstwą abstrakcji, trudniej jest użyć różnych mikroarchitektur w celu optymalizacji pod kątem różnych kompromisów. Ujawnienie szczegółów mikroarchitekturalnych jako gwarancji architektonicznych zamyka mikroarchitekturę w gwarancję kompatybilności. Chociaż oprogramowanie PAL można zoptymalizować tak samo, jak skomplikowane instrukcje, wymaga to znakowania sprzętowo-programowego. Separacja organizacyjna i różnorodność utrudniają kodowanie.

Złożone instrukcje mogą zapewnić bezpieczny dostęp do uprzywilejowanego stanu. Na przykład złożone instrukcje są często atomowe w odniesieniu do przerwań. Chociaż zestaw instrukcji RISC może zapewnić mechanizm na poziomie użytkownika do tymczasowego zawieszania przerwań, być może nawet coś w rodzaju obciążenia połączonego, tak że oprogramowanie wyraźnie ponawia operację, jeśli zostanie przerwane, pod warunkiem, że nie jest to typowe dla RISC.

Podobnie złożona instrukcja może zapewnić kontrolowany dostęp i / lub wykorzystanie uprzywilejowanych informacji. Ponieważ wykonywana operacja kontroluje semantykę, faktycznego naruszenia uprawnień można uniknąć. Alternatywy zorientowane na RISC obejmują kod PAL (który zwykle ma znaczny narzut) i zamaskowany dostęp do rejestrów konfiguracji (lub ukrytych kopii rejestrów), które mają pewien uprzywilejowany stan. Zapewnienie rozwiązania ogólnego (RISC) jest trudniejsze niż rozwiązanie jednego lub kilku szczególnych przypadków (CISC), ale jest silniejsze i mniej podatne na gromadzenie się szczególnych przypadków. Jeśli ktoś uważa, że ​​ważnych szczególnych przypadków jest niewiele, CISC może być bardziej atrakcyjny.

Złożone instrukcje mogą również ukrywać stan przed oprogramowaniem. Jedną z wyraźnych zalet takiego rozwiązania byłoby zapisywanie i przywracanie kontekstu. Dzięki instrukcjom zapisującym i przywracającym stan architektura musi jedynie przekazać rozmiar kontekstu do systemu operacyjnego, a nie konkretne mechanizmy przenoszenia stanu do pamięci. Dzięki temu aplikacje działające w starszym systemie operacyjnym mogą korzystać z rozszerzeń ISA, które dodają stan. (Ponownie oprogramowanie PAL może zapewniać tę samą funkcjonalność).

Znaczna część złożoności x86 wynika z kompatybilności wielu rozszerzeń. Dzięki złożonym i mniej ortogonalnym instrukcjom (przydatnym do zagęszczenia kodu), usuwanie niektórych prac, które okazały się niepotrzebne, unikanie niepotrzebnych łańcuchów zależności (np. Tylko jeden bit przenoszenia, tylko jeden rejestr wielkości przesunięcia dynamicznego), dodawanie pewnej pracy, która się zmieniła powszechnie stosowane i które można zoptymalizować w ramach złożonej instrukcji - każda z nich wymagałaby dodania nowej instrukcji i uczynienia ISA mniej estetycznym.

W wielu przypadkach RISC nie napotkałby takich problemów, ponieważ instrukcje są wysoce ortogonalne i prymitywne. W niektórych przypadkach RISC może wymagać dodania nowych prymitywów, ale zwykle dotyczy to więcej niż jednego zastosowania.

Ponadto, gdy infrastruktura jest gotowa do obsługi złożonych instrukcji, bariery są zmniejszane w przypadku dodatkowych złożonych instrukcji. Oznacza to, że znaczna część kosztów złożonych instrukcji w przypadku braku powtarzalności. Silnie RISC ISA mają dodatkową przeszkodę we wprowadzaniu funkcji CISCy.

Częstotliwość rozszerzenia x86 można również częściowo przypisać jego popularności w obliczeniach ogólnego zastosowania i modelu procesora handlowego (zwiększają również znaczenie zgodności binarnej). RISC ISA często wiązano z dostawcami systemów, co zachęca do węższego skupienia się na aplikacjach, a brak konkurencji dla implementacji konkretnego RISC ISA nieco zniechęca do stosowania rozszerzeń zestawu instrukcji do celów marketingowych. Popularność powoduje również, że koszty opracowywania nowych rozszerzeń są mniej znaczące (jednorazowe wydatki są mniej ważne przy większym wolumenie).

Filozofia kompatybilności z x86 prawdopodobnie również przesuwa się w kierunku rozszerzenia istniejących mechanizmów, a nie zapewnia bardziej czystej przerwy, co oznacza, że ​​na nowe funkcje mają większy wpływ istniejące funkcje. Wyższa częstotliwość wydłużania zachęca również do wprowadzania bardziej stopniowych zmian, co zachęca do ponownego wykorzystywania mechanizmów, dążąc do zmniejszenia ortogonalności.

Porównanie akademickiej prezentacji klasycznego MIPS (który jest podzbiorem nowoczesnych wersji MIPS i wyklucza różne opcjonalne rozszerzenia ISA) z nowoczesnym x86 (który śledzi zgodność binarną z powrotem do 16-bitowego 8086 i quasi-kompatybilność na poziomie zespołu nawet jeszcze dalej) z całym swoim historycznym bagażem nie przedstawia najlepszego przypadku dla CISC ani realistycznego przypadku dla RISC.

Tuż przed wprowadzeniem konfiguracji zestawu instrukcji zredukowanych istniały konfiguracje zestawu instrukcji. Mają swoje aplikacje. szczególnie w przypadku bardzo dużych transferów bloków pamięci z chipsetami o dużej pojemności, które wymagałyby tylko 4-16 bajtów do przesłania całej strony wideo, zamiast długiej pętli na zawsze. to się zmienia, a RISC staje się status quo, ponieważ układy scalone stają się coraz bardziej wyrafinowane, podobnie jak niesamowite karty graficzne w wysokiej klasy kartach graficznych.

Procesor CISC ma więcej zalet niż RISC. Ponieważ wiele razy CISC używa mniej rejestrów sprzętowych i bram XNOR / XOR niż RISC !!!! Wyobraź sobie, że bajty instrukcji w CISC zostaną wykonane - sekwencja, jest tylko jedna bramka logiczna i używany jest rejestr. Jeśli 1 miliard tranzystorów może wytworzyć około 300 milionów bramek logicznych, możesz przetworzyć 300 milionów operatorów lub procesów (IF, równe, matematyczne, zmienne, adresowanie ... itd.) I więcej programów może działać w CISC. Jednak w RISC uruchomienie programu w trybie potokowym zajmuje kilkanaście bramek logicznych. A więc 300 milionów x 50 razy (50 instrukcji) + 15000000000 liczników bitów !!! w tak zwanym RISC. CISC używa więcej sprzętu, aby zredukować oprogramowanie algothrim, które spowalnia procesor.