Czy procesory ARM (najnowsze i stare) używają mikrokodu? Jeśli tak, to po co? Czy ich instrukcje nie są wystarczająco proste, aby można je było wykonać bezpośrednio bez tłumaczenia na mikrooperacje?
12
TL, DR; Podczas gdy procesory ARM używają podobnych koncepcji jak mikrokodowane procesory (np. Istnieje blok sprzętowy, który dekoduje instrukcje do jednej lub większej liczby mikroprocesorów ), nie są one mikrokodowane w tradycyjnym sensie, który używa pamięci ROM do przechowywania każdej mikroinstrukcji, ani czy te mikro-instrukcje / operacje mogą być modyfikowane po wyprodukowaniu na rzeczywistym sprzęcie. Rzeczywiście, procesory ARM używają sterowania przewodowego w dekoderze instrukcji do generowania mikroprocesorów.
W praktyce jednak modyfikacja dekodera instrukcji może być podobna do modyfikacji mikrokodowanego procesora, ponieważ ARM licencjonuje kod źródłowy języka opisu sprzętu ( HDL ) jego architektury procesorów poszczególnym producentom, co znacznie ułatwia implementację modyfikacji na poziomie sprzętowym. Więcej informacji na temat różnic między typowymi dekoderami instrukcji RISC i CISC znajduje się w sekcji Dekoder instrukcji w Wikibook Projekt mikroprocesora.
O ile sama architektura ARM jest nie microcoded w tradycyjnym sensie, poszczególne instrukcje są dekodowane na mniejsze mikro operacji . Nowoczesny procesor ARM jest daleki od „prostego” - chociaż same instrukcje są bardzo ortogonalne, istnieje wiele nowoczesnych technologii (np. Potokowanie, instrukcje superskalarne, wykonywanie poza kolejnością, buforowanie, rozszerzone złożone instrukcje, takie jak jednostki zmiennoprzecinkowe lub instrukcje NEON), które ma nowoczesny rdzeń A9. Rzeczywiście każdy procesor może być wystarczająco prosty do wykonania bez tłumaczenia na mikrooperacje, ale w zasadzie polega to na umieszczeniu „wszystkich jajek w jednym koszyku” - nie można poprawić żadnej możliwej erraty w zestawie instrukcji ani rozwinąć / zmodyfikować jej po produkcji.
Jeśli jednak mówimy tylko o etapie dekodowania instrukcji , to w rzeczywistości wiele procesorów ARM nie jest mikrokodowanych w sposób, który umożliwia modyfikację po fakcie, chociaż może to być spowodowane tym, że większość producentów licencjonujących technologię ARM ma dostęp do rzeczywistej sprzętowy kod źródłowy (napisany w HDL). Zmniejsza to zużycie energii, ponieważ stopień mikrokodu nie jest wymagany, ale poszczególne instrukcje są „kompilowane” w rzeczywiste bloki sprzętowe. Pozwala to również na korektę błędu przez każdego producenta.
Rzeczywiście, nawet w procesorze opartym na CISC (np. X86) nie ma wymogu użycia mikrokodu. W praktyce jednak złożoność zestawu instrukcji, w połączeniu z różnymi różnicami w licencjonowaniu, zużyciu energii i aplikacjach, sprawia, że wybór mikrokodu jest idealny w przypadku x86. W przypadku ARM jest to jednak mniej przydatne, ponieważ zmiany w zestawie instrukcji (dekoderze) są znacznie łatwiejsze do wdrożenia i sterowania pod względem samego sprzętu (ponieważ może to dostosować producent).
Chociaż posiadanie mikrokodu może w niektórych przypadkach uprościć konstrukcję procesora (ponieważ każda instrukcja istnieje jako „mikroprogram” w przeciwieństwie do faktycznego sprzętu), jest to w rzeczywistości tylko dekoder instrukcji (np. Rozszerzenie Thumb-2 , umożliwiający zmienne instrukcje długości, które istnieją, dodając osobny dekoder instrukcji zgodny z dekoderem instrukcji ARM). Chociaż funkcjonalnie jednostki te można zaimplementować za pomocą mikrokodu, nie byłoby to mądre pod względem zużycia energii, ponieważ trzeba zdefiniować moc wyjściową dla każdego sygnału sterującego w samym procesorze, nawet jeśli nie jest to wymagane. To robi nie mają jednak cokolwiek wspólnego z tym, jak „złożony” jest sam procesor, ponieważ rdzenie ARM mają wszystkie nowoczesne konstrukcje, których można się spodziewać (potokowanie, pamięci podręczne instrukcji / danych, bufory mikro-TLB, przewidywanie rozgałęzień, pamięć wirtualna itp.) ).
W przypadku ARM, biorąc pod uwagę ortogonalność zestawu instrukcji, złożoność związana z implementacją takiego podejścia mikrokodowanego przewyższałaby korzyści wynikające z prostej zmiany odpowiedniego sprzętu bezpośrednio w bloku dekodera instrukcji. Chociaż jest to z pewnością możliwe, ostatecznie „wymyśla koło”, mówiąc, że jesteś w stanie bezpośrednio modyfikować (i kompilować / testować / emulować) zmiany w sprzęcie.
W tym przypadku możesz „pomyśleć” o samym kodzie źródłowym ARM jako o typie mikrokodowania, chociaż zamiast przechowywać każdą mikroprocesor / mikroprogram w pamięci ROM, którą można zmodyfikować po fakcie, są one implementowane bezpośrednio w sprzęt w dekoderze instrukcji. Biorąc pod uwagę, że sam dekoder instrukcji jest napisany w VHDL / Verilog, wprowadzanie zmian do istniejących instrukcji jest tak proste, jak modyfikacja kodu źródłowego, rekompilacja i testowanie nowego sprzętu (np. Na FPGA lub symulatorze). Kontrastuje to ze złożonością współczesnego sprzętu x86, który jest znacznie trudniejszy do testowania / symulacji podczas programowania, a jeszcze trudniejszy do modyfikacji po produkcji (ponieważ rozmiar pod względem tranzystorów znacznie przewyższa to, co można uruchomić w nawet najdroższym nowoczesnym FPGA, co daje dodatkową korzyść z korzystania ze sklepu z mikrokodami).fizyczny sprzęt korzystający z FPGA.