Dnia 18.10.2012 Michoo <m...@v...pl> napisał/a:
> On 17.10.2012 22:28, Baranosiu wrote:
>> Z technicznego punktu widzenia rejestr to taka sama pamięć jak RAM czy
>> cache,
>
> Zwłaszcza, że RAM jest pamięcią dynamiczną a cache i rejestry pamięcią
> statyczną(i to też pamięć RAM tak w sumie) więc technicznie to się dość
> mocno różnią. Logicznie to i to jest pamięcią.

Pamięci cache czy RAM są realizowane w różnych technologiach (tak samo
zresztą jak rejestry) ale wszystkie są pamięciami (z punktu widzenia
funkcjonalności, a czy fizycznie to jest kondensator, którego trzeba
"odświeżać" czy zatrzask na tranzystorze, to już tylko kwestia kosztu
produkcji i poboru mocy :D).


>
>> a że nie jest podpięty do szyny adresowej
>
> Której szyny adresowej? Jest ich w komputerze kilka a jak sam zauważyłeś
> rejestry są kawałkiem pamięci - jakoś zaadresować je trzeba.

Miałem na myśli to, że nie mają wspólnej przestrzeni adresowej z RAM-em.

>> ale już na przykład w
>> niektórych procesorach RISC (choćby takie małe Atmegi z rdzeniem AVR)
>> rejestry są jak najbardziej adresowalne.
>
> Bo skoro na pokładzie jest tylko kilka kilo SRAM to umieszczanie tam
> rejestrów jest naturalne. W x86 L1 jest zazwyczaj kilka razy większe a
> pamięć rejestrów niewiele mniejsza od całej pamięci w małym uC.

Chodziło też między innymi o dwie dodatkowe funkcjonalności:
1) DMA może wrzucać dane bezpośrednio do rejestrów procesora.
2) Funkcje biblioteczne mogą działać zarówno na danych w SRAM jak i na
danych w rejestrach (ten sam kod, kwestia podania innego wskaźnika do
danych).

Podałem przykład AVR-a, bo taki mi przyszedł do głowy (akurat pisałem
program na taki mikrokontroler :D), ale wiele procesorów ma tego typu
wynalazki jak "zerowe strony pamięci" czy "adresowalne cache", choć
nie zawsze te obszary mają w 100% identyczną funkcjonalność jak
rejestry, no ale z drugiej strony nawet w x86 nie wszystkich rejestrów
można użyć do wszystkiego (pomijam rejestry tupu program counter czy
stack pointer, bo ich specjalne przeznaczenie jest oczywiste).

>> Takie pierdoły jak "register
>> rename" wynikają z prostego faktu, że nawet tanie mikrokontrolery za
>> 20zł mają 32 ortogonalne rejestry (nawet Amiga 30 lat temu miała
>> 16 rejestrów 32-bitowych, choć nie w pełni ortogonalnych) a Intel robi
>> "wielką rewolucję" że w 64-bitowej maszynie raptem dodaje 8
>> dodatkowych rejestrów do 4 już istniejących (reszta to indeksowe i
>> segmentowe) i tylko dlatego, że AMD to zrobiło wcześniej, więc trzeba
>> było "dogonić" konkurencję :D
>
> Ale zauważyłeś że nowe x86 mają takie ciekawostki jak np. prefetch,
> których w RISC nie ma?

Prefetch to miał nawet MOS6502 (z 1975 roku!) w Commodore C64 (inna
rzecz, że tylko jednego bajtu :D) a co dopiero współczesne RISC!
Chociażby wspomniane procesory Sparc z serii V9 (przykładem jest
SparcUltra) już w 1995 roku miały wszystko o czym wspomniałeś, łącznie
z 9-poziomowym pipeline, prefetchem, przełączanymi ramkami rejestrów i
różnymi innymi "bajerami". Piszę o Sparcach, bo akurat w tamtych
czasach dużo miałem z nimi do czynienia i dużo na nie programowałem
ale tego typu rozwiązania były (i są nadal) w RISC-ach
powszechne. Poczytaj na przykład o najnowszych ARM-ach (czy o
Intelowych XScale - to są praktycznie klony ARM :D) i się zdziwisz ile
fajnych rzeczy może mieć procesor, na przykład wykonanie się każdej
instrukcji może zależeć od ustawienia flag procesora (przykład
algorytmu Euklidesa dla procesora ARM bez użycia odgałęzień i tylko
przy użyciu 4 instrukcji maszynowych możesz znaleźć na Wikipedii razem
z wyjaśnieniem, więc nie będę się szczegółowo rozpisywał :D).
Wiem że Intel ma genialny marketing i potrafi przekonać
niezorientowanych w temacie, że jest pionierem i wszystko ma najlepsze
:D

>>
>> Pipeline? W 1996 roku na studiach programowałem procesor
>> SparcUltra, który (pomijając że w pełni 64-bitowy) wykonywał dwie
>> instrukcje w jednym cyklu zegara i trzeba było uważać jak się pisało
>> programy w assemblerze, bo jak się po CALL _adres nie dało instrukcji
>> NOP, to drugi potok mógł zdążyć wykonać instrukcję za "CALL" zanim się
>> skok wykonał :D
>
> Jeżeli to skutkowało błędami to był to kiepski procesor. W momencie gdy
> pierwszy dekoder rozkazów trafił na instrukcję skoku (ret, jmp, etc.)
> pipeline powinien być blokowany (tzn w niepopsutych rozwiązaniach to
> działa tak, że część drugiej instrukcji się wykona, tak gdzieś do zapisu
> wyniku).

Oj i tu się nie zgodzę, bo to jest błąd programisty a nie procesora,
załóżmy że mamy tego typu program (R1 i R2 to rejestry, znaczenie
instrukcji chyba oczywiste, składnia tzw. AT&T czyli nazwy rejestrów w
programie poprzedzone znakiem %):

call _przykladowa_funkcja
inc %R1
[kolejne instrukcje]

_przykladowa_funkcja:
adc %R2,%R3
ret

I teraz... dlaczego inkrementacja R1 miałaby zostać zmarnowana, skoro
wewnątrz _przykladowa_funkcja rejestr R1 nie jest wykorzystany? Po
powrocie z tej funkcji jesteśmy o jedną instrukcję "do przodu" :D Jak
ktoś nie chce takiego zachowania, to może po call wstawić nop i nie ma
problemu (można też zlecić assemblerowi automatyczne wstawienie nopów
po rozgałęzieniach bądź wyświetlanie ostrzeżeń że tego typu sytuacja może
wystąpić). Projektanci procesora zamiast wstawiać sprzętowe
zatrzymywanie potoku stwierdzili, że wybór czy blokować potok czy nie
można zostawić programiście, bo czasem niezablokowanie potoku może dać
zysk - czy to dobrze czy źle, to już kwestia gustu :D W sumie jeśli już,
to w assemblerze pisze się bardzo małe fragmenty programu (w większości
przypadków nie używa się go w ogóle), a kompilatory języków wyższego
poziomu wygenerują kod assemblerowy, który robi co trzeba :D

>> "Nikt nie widział eax" bo pewnie nikt do środka nie zaglądał :D A tak
>> na serio, to Intele nie są procesorami tzw. hardwired (takie są na
>> przykład ARM-y, AVR-y itd.) tylko mają prosty rdzeń i mikrokodem
>> załatwiają resztę :D W sumie mogliby udostępnić możliwość ładowania
>> własnego mikrokodu, wtedy każdy mógłby stworzyć swój assembler (choć
>> od takich rzeczy, to akurat układy FPGA są lepsze :D).
>
> Jesteś pewien, ze ten mikrokod nie jest przynajmniej częściowo wsadem
> konfiguracyjnym dla bloków FPGA-like wewnątrz procesora? Przy 3GHz
> klasyczny RISC musiałby pracować chyba szybciej niż podłoże krzemowe na
> to pozwala...

No tak się składa, że 4GHz RISC z 32 jednostkami APU powstał w 2005
roku i jest używany w dużych maszynach IBM, a jego okrojona wersja
(3.2GHz i 8APU) znalazła w 2006 roku swoje miejsce w konsolach
PlayStation3 :D Owszem, podłoże krzemowe na to nie pozwala, ale
podłoże z arsenku galu już jak najbardziej (teoretycznie na arsenku
galu można osiągnąć prędkości rzędu setek gigaherców, ale problemem
staje się odprowadzanie ciepła i czas reakcji układów peryferyjnych, w
ciągu jednego cyklu zegara światło zdążyłoby pokonać drogę niecałego
centymetra :D).

Co do mikrokodu: owszem, można zaktualizować mikrokod w procesorach
Intela, ale takiej aktualizacji nie może sobie napisać każdy (jedna
rzecz to brak dostępnej specyfikacji, a druga, to konieczność
cyfrowego podpisania takiego "wsadu" certyfikatem Intela, bo inaczej
procesor go nie przyjmie - to jest zabezpieczenie aby wirusy nie mogły
uwalić procesora :D).