16 rejestrów z nieniszczącymi instrukcjami 3-operandowymi jest prawdopodobnie lepsza.
Należy jednak również rozważyć zrobienie czegoś ciekawego z tymi bitami instrukcji. W przypadku homebrew prawdopodobnie nie dbasz o rezerwowanie jakichkolwiek przyszłych rozszerzeń i nie chcesz dodawać mnóstwa dodatkowych opcodes (like PPC does).
ARM przyjmuje interesujące podejście polegające na tym, że jeden operand do każdej instrukcji przechodzi przez the barrel shifter, więc każda instrukcja jest instrukcją "shift-and-whatever" za darmo. Jest to obsługiwane nawet w trybie "kciuka", gdzie najczęściej używane instrukcje to tylko 16 bitów.(W trybie ARM ma tradycyjną RISC 32bit stały rozmiar instrukcji. Dedykuje to 4 z tych bitów opiera wykonania dla każdej instrukcji.)
Pamiętam badanie dotyczące zysków perf od podwojenie liczby rejestrów w sposób teoretyczna architektura, dla SPECinta lub czegoś takiego. 8-> 16 było może 5 lub 10%, 16-> 32 tylko kilka%, a 32-> 64 było jeszcze mniejsze.
Więc 16 rejestrów całkowitych jest "wystarczającą" przez większość czasu, chyba że pracujesz z int32_t dużo, ponieważ każda taka wartość zajmie dwa 16 bitowe rejestry. x86-64 ma tylko 16 rejestrów GP, a większość funkcji może dość dobrze utrzymywać ich stan na żywo w rejestrach. Nawet w pętlach, które wywołują wywołania funkcji, w ABI jest wystarczająco dużo rejestrów zachowujących wywołania, które często się nie pojawiają w pętli.
Zyski w rozmiarze kodu i liczbie instrukcji z 3-operandowych instrukcji będą większe niż przy zapisywaniu sporadycznego rozlewania/ponownego ładowania. Wyjście gcc musi przez cały czas być mov i używać lea jako nieniszczącego add/shift.
Jeśli chcesz zoptymalizować CPU dla oprogramowania potoku ukryć opóźnienia obciążenia pamięci (which is simpler than full out-of-order execution), więcej rejestry są świetne, esp. jeśli nie masz zmiany nazwy rejestru. Jednak nie jestem pewien, jak dobre kompilatory są na static instruction scheduling. Nie jest to już gorący temat, ponieważ wszystkie wydajne procesory są nieczynne. (OTOH, wiele programów, których ludzie faktycznie używają, działa na procesorach ARM w kolejności w smartfonach.) Nie mam doświadczenia, próbując zmusić kompilatory do optymalizacji pod kątem procesorów w kolejności, więc IDK, jak opłacalne jest poleganie na że.
Jeśli twój procesor jest tak prosty, że nie może zrobić nic więcej, gdy ładunek jest w trakcie lotu, to prawdopodobnie nie ma znaczenia. (To się robi naprawdę ręcznie faliste bo nie wiem wystarczająco dużo o co jest praktyczne dla prostej konstrukcji. Nawet „proste” w zamówienie nowoczesne procesory są potokowych.)
64 rejestrów jest miejsce „zbyt wiele "terytorium, gdzie zapisywanie/przywracanie ich zajmuje dużo kodu. Ilość pamięci jest prawdopodobnie nadal pomijalna, ale ponieważ nie możesz zapętlić rejestrów, potrzebujesz 64 instrukcji.
Jeśli projektowaniu ISA od podstaw, spojrzeć Agner Fog's CRISC proposal i wynikającą z dyskusji. Twoje cele są bardzo różne (wysoka wydajność/energooszczędny 64-bitowy procesor w porównaniu z prostym 16-bitowym), więc twoje ISA będą oczywiście bardzo różne. Jednak dyskusja może sprawić, że pomyślisz o rzeczach, których nie rozważałeś lub o pomysłach, które chcesz wypróbować.
Już po raz pierwszy (w pakiecie x86 przykro tylko, że wiem). Większość programów, które wprowadziłem przez takie rzeczy jak IDA, zwykle używa rejestrów Eax przez Edx, więc jest ich 4. Wtedy masz Ebp i Esp, więc 6. Eip nie potrzebuje ALU. Eflags (znowu nie ma potrzeby ALU) ESI i EDI tworzą 8. Tak więc od pierwszej chwili myślę, że większość programów nie używa więcej niż 16 rejestrów. Być może brakuje mi kilku, ale myślę, że dobrym pierwszym testem poczytalności służącym do określenia tego byłoby sprawdzenie, co gcc kompiluje i znajduje, czy używa nawet więcej niż 16 rejestrów w ALU. – arduic
Gdzie zamierzasz zakodować tryb adresowania? –
@WeatherVane To RISC - ładuje i przechowuje jawne operacje z własnym kodem operacyjnym. To homebrew-cpu - jedyne tryby adresowania dla ładunków i sklepów to 8 bitowe natychmiastowe przesunięcia od zera, z komputera lub z innego rejestru. – fadedbee