03.03.2015 20:27
[#5]
Re: Apollo Phoenix Core v2000 Vampire 600
@Pawelek, post #4
SysInfo w wynikach testu nie pokazuje prawdziwej prędkości 68060.
http://aminet.net/util/moni/sspeed26.lha
http://aminet.net/util/moni/sspeed26.lha
To będzie chyba najszybszy klasyk (bez PPC). 03.03.2015 23:33
[#11]
Re: Apollo Phoenix Core v2000 Vampire 600
@sanjyuubi, post #10
Mam nadzieje ze jeszcze to udoskonala i wyjdzie dla amigi 1200. Jeszcze zeby tylko elbox zmniejszyl tego mediatora znacznie (celem uzycia kart mini-pci-express +pci-express dla grafiki typu low-profile).Wtedy wszystko moze by sie udalo zmiescic wewnatrz oryginalnej obudowy do a1200.
04.03.2015 11:03
[#16]
Re: Apollo Phoenix Core v2000 Vampire 600
@Pawelek, post #15
To czego byś chciał - (znacznie) większej wydajności, czy kompatybilności? Czy warto żałować programów, które są przekombinowane, napisane z dokładnością co do cyklu zegara cpu tak, że na czymś szybszym będą działać błędnie?
Apollo core z punktu widzenia programu powinno wyglądać jak MC68000 (ale dlaczego sysinfo pokazało to jako 68ec020? Pewnie dlatego.... że to sysinfo ;), a w środku jest zoptymalizowane - instrukcje wykonują się w 1 cyklu (albo nawet kilka na cykl, bo to ponoć jest superskalarne), jest w pełni 32-bitowe itp. Ja bym to nazwał np. 68018 ;)
Skoro w low-endowej fpga wyciągają 200MHz, to w high-endowej pewnie pod GHz - i to mi się bardzo podoba: zoptymalizowany MC68000 1GHz, czegóż więcej trzeba? A.. tak, podobnie zoptymalizowanej AGA :)
Apollo core z punktu widzenia programu powinno wyglądać jak MC68000 (ale dlaczego sysinfo pokazało to jako 68ec020? Pewnie dlatego.... że to sysinfo ;), a w środku jest zoptymalizowane - instrukcje wykonują się w 1 cyklu (albo nawet kilka na cykl, bo to ponoć jest superskalarne), jest w pełni 32-bitowe itp. Ja bym to nazwał np. 68018 ;)
Skoro w low-endowej fpga wyciągają 200MHz, to w high-endowej pewnie pod GHz - i to mi się bardzo podoba: zoptymalizowany MC68000 1GHz, czegóż więcej trzeba? A.. tak, podobnie zoptymalizowanej AGA :)
04.03.2015 11:17
[#18]
Re: Apollo Phoenix Core v2000 Vampire 600
@Pawelek, post #17
Ale po co? Czy MC68000, który będzie kilka razy szybszy od najszybszego MC68060, nie będzie od niego lepszy? 68020 jest już trudniejszy w implementacji w fpga, nie wspominając nawet o 68060. Bo co takiego wniósłby core 68060, poza tym, że możnaby uruchamiać kilka programów wymagających 68060? 68020 ma jeszcze jakiś sens, bo sporo softu go wymaga. Może dlatego apollo-core w sysinfo się identyfikuje jako 68020? No ale tu coś zaczyna się nie zgadzać, bo 68020 ma dodatkowe instrukcje i tryby adresowania, a "Fully User-Code Compatible with MC68000" tego nie potwierdza. Chyba, że istnieje jeszcze inne apollo-core.
04.03.2015 11:52
[#19]
Re: Apollo Phoenix Core v2000 Vampire 600
@BigBang, post #16
Do GHz nie dociągną, ale jakieś 400MHz to spokojnie na lepszym FPGA można by osiągnąć. Problem jest tylko taki że nie da się łatwo podmienić tego Cyclone II/III na jakiegoś Strasix'a bez redesignu całej płyty. Raczej takie coś nie powstanie. Najwyżej jak będą robić akcelerator do A1200 to może wybiorą jakiś Cyclone V
04.03.2015 12:12
[#21]
Re: Apollo Phoenix Core v2000 Vampire 600
@recedent, post #20
Bo implementacja 68000 w FPGA jest bardzo zoptymalizowana w porównaniu z oryginałem? I doczytałem już na ich forum, że jest jednak wersja 68020 - czyli sysinfo tu nie kłamie.
Idąc dalej, implementacja ta jest superskalarna - ma dwa potoki, czyli w 1 cyklu wykonuje dwie instrukcje, to efektywność lepsza niż w 68060 (tam, jak piszą, też są dwa potoki, ale instrukcje wykonują się w więcej niż 1 cyklu). Czyli działa tu stara prawda o mips-ach - nie da się jednego z drugim porównać liniowo MHz do MHz.
Idąc dalej, implementacja ta jest superskalarna - ma dwa potoki, czyli w 1 cyklu wykonuje dwie instrukcje, to efektywność lepsza niż w 68060 (tam, jak piszą, też są dwa potoki, ale instrukcje wykonują się w więcej niż 1 cyklu). Czyli działa tu stara prawda o mips-ach - nie da się jednego z drugim porównać liniowo MHz do MHz.
04.03.2015 12:33
[#23]
Re: Apollo Phoenix Core v2000 Vampire 600
@MasterM, post #22
To nie jest emulacja, to jest implementacja architektury i modelu programowego M68000.
Z punktu widzenia programu jest nieistotne, jak sobie procesor radzi w środku z wykonywaniem instrukcji. Program ma się wykonać tak samo jak na każdej innej implementacji M68000 (pomijając cuda na kiju typu samomodyfikujący się kod, albo chowanie danych w najstarszym bajcie adresu, gdy cpu ma 24-bitową adresację).
A jak to sobie implementator rozwiąże to zależy tylko od niego. Może użyć mniej tranzystorów i wewnętrzenie rozbijać każdą instrukcje na mikroinstrukcje, wykonując ją wieloetapowo, co nie jest efektywne (ale to znowu pozwala na superskalarność). A może każdą instrukcję z-hardwire-ować, czyli całą jej logikę zrealizować w krzemie, aby osiągnąć maksymalną wydajność. Może użyć cache jedno lub wielopoziomowe, może użyć wielu potoków, aby zrównoleglić przetwarzanie, może sobie dorzucić logikę próbującą przewidywać skoki, itp. Taki 68000 z oryginalnym będzie miał wspólną tylko listę rozkazów i złącza elektryczne (ale może mieć ich więcej, bo np. pełną, 32-bit szynę danych i adresową)
Z punktu widzenia programu jest nieistotne, jak sobie procesor radzi w środku z wykonywaniem instrukcji. Program ma się wykonać tak samo jak na każdej innej implementacji M68000 (pomijając cuda na kiju typu samomodyfikujący się kod, albo chowanie danych w najstarszym bajcie adresu, gdy cpu ma 24-bitową adresację).
A jak to sobie implementator rozwiąże to zależy tylko od niego. Może użyć mniej tranzystorów i wewnętrzenie rozbijać każdą instrukcje na mikroinstrukcje, wykonując ją wieloetapowo, co nie jest efektywne (ale to znowu pozwala na superskalarność). A może każdą instrukcję z-hardwire-ować, czyli całą jej logikę zrealizować w krzemie, aby osiągnąć maksymalną wydajność. Może użyć cache jedno lub wielopoziomowe, może użyć wielu potoków, aby zrównoleglić przetwarzanie, może sobie dorzucić logikę próbującą przewidywać skoki, itp. Taki 68000 z oryginalnym będzie miał wspólną tylko listę rozkazów i złącza elektryczne (ale może mieć ich więcej, bo np. pełną, 32-bit szynę danych i adresową)
04.03.2015 13:20
[#26]
Re: Apollo Phoenix Core v2000 Vampire 600
@Pawelek, post #25
Patrzę w manuala do 68060 i piszą tam, że najwięcej instrukcji mają 68020 i 68030, potem 68040/68060 i najmniej 68000/68010. Tak samo 68060 ma więcej trybów adresowania niż 68000. Przy okazji sprostowanie - jest jednak trochę instrukcji, które 68060 wykonuje w jednym cyklu! Zatem byłoby trudniej nawet z punktu widzenia samej listy instrukcji.
A oryginalny 68060 jest zaawansowany nie ze względu na taką, czy inną listę rozkazów, tylko ma właśnie przetwarzanie potokowe i superskalarne, przewidywanie skoków, spore cache, dodatkowo układy zarządzające zużyciem energii, kompatybilność z peryferiami 5V i 3.3V i pewnie jeszcze jakieś inne udogodnienia.
A oryginalny 68060 jest zaawansowany nie ze względu na taką, czy inną listę rozkazów, tylko ma właśnie przetwarzanie potokowe i superskalarne, przewidywanie skoków, spore cache, dodatkowo układy zarządzające zużyciem energii, kompatybilność z peryferiami 5V i 3.3V i pewnie jeszcze jakieś inne udogodnienia.
04.03.2015 14:00
[#28]
Re: Apollo Phoenix Core v2000 Vampire 600
@Pawelek, post #27
No ma trochę mniej niż 68020/68030, stąd potrzebna jest ta biblioteka. Ale ma więcej niż 68000. Chcesz polemizować z manualem Motoroli?
Z punktu widzenia systemu operacyjnego jest obojętne, ile bajerów ma cpu w środku, byle wykonywał instrukcje zgodnie z modelem programowym M68k.
Twórcy apollo-core się spisali, bo według nich osiągnęli większą efektywność wykonywania kodu niż w oryginalnym 68060.
Z punktu widzenia systemu operacyjnego jest obojętne, ile bajerów ma cpu w środku, byle wykonywał instrukcje zgodnie z modelem programowym M68k.
Twórcy apollo-core się spisali, bo według nich osiągnęli większą efektywność wykonywania kodu niż w oryginalnym 68060.
04.03.2015 14:13
[#30]
Re: Apollo Phoenix Core v2000 Vampire 600
@Pawelek, post #27
Nie mów mi, że chciałbyś mieć 060 i to golasa baz MMU i FPU zaimplementowanego tylko na poziomie instrukcji. Phoenix core osiągnął taką wydajność ponieważ sporo bliżej mu rozwiązaniami wewnętrznymi do 060 niż 000. Jak chcesz mieć klona 060, to ważna jest tez kompatybilność, a 040/060 sa o wiele bardziej rozbudowanymi procesorami niż 000, mają więcej trybów pracy, porąbane moduły cache i to, że nie mają kilku instrukcji z 68000 nie znaczy, że nie mają też swoich, w dodatku są procesorami synchronicznymi. zapewnienie kompatybilności na tym poziomie jest trudne, a kto kupi akcelerator apollo do swojej A1200 zamiast 060 jeśli nie będzie mógł pooglądać swoich demek, a jeśli mamy gdzieś kompatybilność, to znaczy, że tworzymy całkiem nowy procesor, a wtedy trzeba stworzyć nowe oprogramowanie. nie wszystkim coś takiego będzie się podobało.