03.09.2014 15:25
[#1]
Koprocesor w FPGA
Jest kilka watkow na temat tworzenia nowej wersji procesora zgodnego z 68K.
Moje pytanie jest takie: czy nie lepiej zrobic implementacje koprocesora zgodnego z 6888x do prockow 020, 030. Jaka jest szybkos oryginalu kazdy wie kto go uzywal.
Czy mialo by to jakis sens pod wzgledem komunikacji CPU<->FPU?
Czy podlaczenie np FPU 100MHz do 030 40MHz bylo by jakos oplacalne w sensie ilosci wykonanych instrukcji np gdyby jedna operacja zmiennoprzecinkowa wykonywala sie w jednym cyklu?
Moje pytanie jest takie: czy nie lepiej zrobic implementacje koprocesora zgodnego z 6888x do prockow 020, 030. Jaka jest szybkos oryginalu kazdy wie kto go uzywal.
Czy mialo by to jakis sens pod wzgledem komunikacji CPU<->FPU?
Czy podlaczenie np FPU 100MHz do 030 40MHz bylo by jakos oplacalne w sensie ilosci wykonanych instrukcji np gdyby jedna operacja zmiennoprzecinkowa wykonywala sie w jednym cyklu?
03.09.2014 15:52
[#2]
Re: Koprocesor w FPGA
@Phibrizzo, post #1
FPU niekoniecznie przyśpiesza obliczenia, tylko zwiększa precyzję obliczeń, w dokumentacji którejś biblioteki (nie pamiętam której) potrzebnej do odtwarzania mp3 jest napisane, że wersja FPU działa wolniej, ale jest precyzyjniejsza. Podłączenie FPU w zasadzie to chyba ma tylko sens dla programów, które z niego korzystają, większość ludzi zazwyczaj takich programów nie używa.
03.09.2014 16:13
[#3]
Re: Koprocesor w FPGA
@sanjyuubi, post #2
To na FPU 100Mhz powinny plynnie sie dekodowac mp3 na karcie z 030 :) , chyba że biblioteka mpega.library w wersji FPU to nie oznacza że działa tylko na FPU a jest wspomagana i korzysta z CPU i FPU razem, jak to jest ?
Ostatnia aktualizacja: 03.09.2014 16:14:57 przez Pawelek
Ostatnia aktualizacja: 03.09.2014 16:14:57 przez Pawelek
03.09.2014 16:28
[#4]
Re: Koprocesor w FPGA
@Phibrizzo, post #1
Pod pewnymi względami szybkość FPU ma duże znaczenie (w kwestii samego wykonywania instrukcji), pod innymi zawsze będzie to zależne od prędkości obsługi przez CPU (zwalnianie magistrali, przesyłanie danych) więc idealny przypadek byłby taki żeby FPU było zintegrowane razem z CPU w FPGA i używając wewnętrznych interconnectów, a na zewnątrz wystawał jedynie interfejs pamięci i standardowe sygnały sterujące.
03.09.2014 16:30
[#5]
Re: Koprocesor w FPGA
@Pawelek, post #3
FPU jest jakby modułem procesora, taktowanie go większym zegarem sprawi tylko, że szybciej zwróci wynik, ale w pewnym momencie wąskim gardłem staje się procesor, bo prędkość czytania instrukcji z RAMu się nie zwiększa. Procesor musi działać cały czas i wykonywać resztę obliczeń na liczbach całkowitych, FPU nie jest jednostką niezależną.
04.09.2014 16:55
[#6]
Re: Koprocesor w FPGA
@sanjyuubi, post #5
Nie orietuje sie jak wyglada taktozernosc 6888x oraz czy procesor glowny zawsze czeka na odpowiedz od FPU, czy tez moze wykonac w tym czasie inna instrukcje staloprzecinkowa.
Jednak gdyby FPU przesylal do CPU wynik najszybciej jak tylko sie da, to jaki teoretycznie bylby przyrost predkosci w stosunku do 6888x? 5%, 10%, 50%?
Jednak gdyby FPU przesylal do CPU wynik najszybciej jak tylko sie da, to jaki teoretycznie bylby przyrost predkosci w stosunku do 6888x? 5%, 10%, 50%?
04.09.2014 18:12
[#7]
Re: Koprocesor w FPGA
@Phibrizzo, post #6
Procesor zawsze czeka na odpowiedź FPU. Z poziomu programisty po dołożeniu koprocesora, pojawia się po prostu więcej instrukcji, dlatego napisałem, że jest to tak jakby moduł rozszerzający, a jeśli procesor nie potrafi wykonywać więcej niż jednej instrukcji w tym samym czasie, to będzie zawsze czekał, aż bieżąca instrukcja się zakończy. Przyśpieszenie będzie widoczne póki cykl koprocesora jest dłuższy niż cykl szyny procesora, później to już tylko kod w cache może jeszcze trochę przyśpieszyć.
04.09.2014 23:04
[#9]
Re: Koprocesor w FPGA
@sanjyuubi, post #7
Jesteś pewien, że procesor zawsze oczekuje na odpowiedz FPU? Bo mi się wydawało że od 68882 (koprocesor wykonuje operację na wew. swoich rejestach), a procesor może lecieć dalej ze swoimi rzeczami, aż do momentu kiedy natrafi na instrukcję, która korzysta z koprocesora (w tedy ten o ile jeszcze nie policzył, zatrzymuje procek).
Najbardziej problematyczną operacją dla CPU jest dzielenie, które na 68000 zabiera chyba pomad 100 cykli. Gdyby program korzystał z FPU i FPU zrobił by to w jednym cyklu procesora, przyspieszenie było by rzeczywiste i duże.
Choć konstrukcja FPU 68882 jest dużo prostsza od konstrukcji 68000 i jest możliwa do stworzenia, to i tak jest to perspektywa odległa, bo kto to zrobi? :-/
Z tego co wiem w Intelu procesor musiał czekać na koprocesor, 68060 właśnie tym wygrywała, że nie musiała czekać, robiła swoje i można było wykonać (w teorii) nawet trzy operacje na raz (dwa na superspieralnych jednostkach ALU i jedną na FPU). Mogę się mylić, bo sam nigdy tego nie testowałem.
Ostatnia aktualizacja: 04.09.2014 23:05:59 przez flops
Najbardziej problematyczną operacją dla CPU jest dzielenie, które na 68000 zabiera chyba pomad 100 cykli. Gdyby program korzystał z FPU i FPU zrobił by to w jednym cyklu procesora, przyspieszenie było by rzeczywiste i duże.
Choć konstrukcja FPU 68882 jest dużo prostsza od konstrukcji 68000 i jest możliwa do stworzenia, to i tak jest to perspektywa odległa, bo kto to zrobi? :-/
Z tego co wiem w Intelu procesor musiał czekać na koprocesor, 68060 właśnie tym wygrywała, że nie musiała czekać, robiła swoje i można było wykonać (w teorii) nawet trzy operacje na raz (dwa na superspieralnych jednostkach ALU i jedną na FPU). Mogę się mylić, bo sam nigdy tego nie testowałem.
Ostatnia aktualizacja: 04.09.2014 23:05:59 przez flops
05.09.2014 00:13
[#10]
Re: Koprocesor w FPGA
@flops, post #9
Hmmm, 68882 (68881 także) nie jest chyba prostszy od 68000. 68882 jest zbudowany ze 176 000 tranzystorów, podczas gdy 68000 (jak sama nazwa wskazuje) z zaledwie 68 000.
Według Wiki i BBoAH, 68882 otrzymuje operandy od CPU i wtedy CPU może rozpocząć wykonywanie kolejnej instrukcji, równolegle z tą wykonywaną z FPU. Zapewne są instrukcje które blokują CPU do zakończenia operacji na FPU, gdyż ich wykonanie zależy wyniku operacji FPU (np. instrukcje warunkowe).
Według Wiki i BBoAH, 68882 otrzymuje operandy od CPU i wtedy CPU może rozpocząć wykonywanie kolejnej instrukcji, równolegle z tą wykonywaną z FPU. Zapewne są instrukcje które blokują CPU do zakończenia operacji na FPU, gdyż ich wykonanie zależy wyniku operacji FPU (np. instrukcje warunkowe).
05.09.2014 06:55
[#11]
Re: Koprocesor w FPGA
@flops, post #9
Masz rację. Pomyliło mi się z tym że MC68881 nie może wykonywać współbieżnie dwóch instrukcji, a 68882 może. Zajrzałem do instrukcji 68020 i może on wykonywać kod niezależnie od FPU, jednak procesor musi sprawdzać rejestr koprocesora i z tego powodu zejście prędkością FPU poniżej czasu pomiędzy wydaniem instrukcji, a sprawdzeniem rejestru nie będzie już wskazywała przyrostu prędkości (chyba, że przyśpieszymy procesor). Analogicznie to tak jak wylutować kości 80ns od pamięci CHIP i wlutować 50ns, przyrostu prędkości nie będzie, bo kontroler tego nie wykorzysta, a nawet gdyby wykorzystał, to np. w A500/600 nic to nie da, bo 68000 przy 7MHz mógłby pracować w pełni wydajności nawet przy kościach 200ns.
Ciekawe jaka jest granica odczuwalnej prędkości koprocesora dla 030 25MHz.
Ciekawe jaka jest granica odczuwalnej prędkości koprocesora dla 030 25MHz.