Ciekawe jak to by się skalowało do ISA z dużym zbiorem rozkazów. Podejrzewam, że w przypadku x86 złożoność byłaby gigantyczna.
Tak czy inaczej, wynik niezły. Przydałby się fontend C. :-)Zawsze możesz ograniczyć ilość instrukcji. Jak to robią duże kompilatory.
Może historia się powtórzy i ktoś odkryje, że mały zbiór instrukcji x86 jest szybszy niż cała reszta. Np ten zestaw o którym wspominał Keller. Że procesory głównie wykonują 6 instrukcji i optymalizacje w tym obszarze dają największy zysk.
Pewnie dzisiaj nie jest to możliwe pod względem wydajności, ale może być pod względem zużycia energii lub zajętości pamięci/wykorzystania cache/przewidywania. Ewentualnie zbudowania bardziej wydajnego układu.
Z tymi 6 instrukcjami to jest na pewno jakieś uproszczenie.
Może chodziło mu o klasy instrukcji (load, store, jmp, cmp, stos, arytmetyka),albo o reprezentację jako µops.W praktyce nawet dla prostego mov masz spory wybór, bo możesz przesyłać różne szerokości słowa. Masz rozkazy SIMD, które dają ogromny przyrost wydajności, ale nie wszędzie możesz ich użyć. Do tego wybór pomiędzy warunkowymi skokami i predykowanymi instrukcjami (CMOV, AVX-512). Znacznie bardziej złożona alokacja rejestrów (kilkanaście GPR w x86-64 vs dwa w 6502).
Ale chyba jeszcze większym problemem byłby fakt, że architektura jest OoO i konstruując pętlę musisz w praktyce estymować dostępność zasobów w CPU i śledzić zależności między instrukcjami. Nie wiem, jak można by to pogodzić z założeniami tego projektu, bo już teraz jest on zaskakująco złożony jak na codegen do bardzo prostej architektury.
Domyślam się, że chodziło mu o to, że procesory nie działają cały czas przetwarzając jakieś ogromne ilości danych. Większość czasu idlują, przetwarzają jakąś pętlę oczekiwania, reagują na przerwanie zegara. Nawet jeśli udamy się dalej. Też nie robią nic wyszukanego w standardowym scenariuszu użytkownika. Przez ułamek sekundy zajmują się reakcją na zdarzenie i przetworzeniem danych.
Nie na darmo są rdzenie heterogeniczne.
