05.02.2016 17:28
[#121]
Re: RTG i Vampire 600 V2
@pisklak, post #119
Podzielam Twoje zdanie. Trzymanie się starej nomenklatury niczego nie wnosi.
Rozwój to jedyna droga. Ci co stoją w miejscu, to stoją. A reszta pędzi do przodu.
Bardzo dobra decyzja ! Dodanie nowych rozszerzeń do CPU. W intelu/AMD to norma, dodawanie nowych funkcji do prockow. Dlatego wg. Mnie żaden problem dla programisty który skompiluje wersje pod standardowy CPU, oraz pod Vampirka. A pamiętajmy że jak posiadaczy będzie więcej, jak wejdą wersje pod pod A1200/A500, to chęć na programy także wzrośnie. Chętnie bym widział VLC Player. Projekt otwarty na wszystkie platformy.
A kto chce zostać na 50 MHz to niech zostanie i dalej się bawi. Ją uważam że ten projekt jest o niebo lepszy od Amigi typu Cloanto czy Amikit....😁
Rozwój to jedyna droga. Ci co stoją w miejscu, to stoją. A reszta pędzi do przodu.
Bardzo dobra decyzja ! Dodanie nowych rozszerzeń do CPU. W intelu/AMD to norma, dodawanie nowych funkcji do prockow. Dlatego wg. Mnie żaden problem dla programisty który skompiluje wersje pod standardowy CPU, oraz pod Vampirka. A pamiętajmy że jak posiadaczy będzie więcej, jak wejdą wersje pod pod A1200/A500, to chęć na programy także wzrośnie. Chętnie bym widział VLC Player. Projekt otwarty na wszystkie platformy.
A kto chce zostać na 50 MHz to niech zostanie i dalej się bawi. Ją uważam że ten projekt jest o niebo lepszy od Amigi typu Cloanto czy Amikit....😁
05.02.2016 17:29
[#122]
Re: RTG i Vampire 600 V2
@pisklak, post #112
Jesli sa zrodla to mozna je zobaczyc. Sama optymalizacja kodu jest zwykle prosta, ale trzeba znac wszystkie mozliwosci nowego procesora, np, kolejnosc instrukcji, tak zeby 3 lub wiecej (przy fuzji) wykonac w jednym cyklu. Nowe instrukcje moga byc uzyteczne. Tylko jezeli to sa specjalizowane instrukcje graficzne to trzeba sie znac na dekodowaniu grafiki, a tym sie nie zajmowalem, bo wtedy trzeba by procedure napisac w zasadzie od nowa. Jezeli riva uzywa mpeg.library do obslugi dzwieku, to mozna zasemblowac wersje meynafa z pominieciem optymalizacji mnozenia pod 68030, powinna to byc wtedy najszybsza mpeg.library w wersji integer dla Apollo. Niepotrzebnie Gunnar poroznil sie z meynafem, bo meynaf ma duze doswiadczenie zarowno w dekodowaniu formatow graficznych, jak i ich optymalizacji. Tym bardziej, ze w koncu Gunnar chyba i tak zrezygnowal z zewnetrznej emulacji instrukcji CPU, choc nie jestem tego pewien na 100%.
05.02.2016 17:42
[#124]
Re: RTG i Vampire 600 V2
@xtro, post #123
VLC Player. Projekt otwarty na wszystkie platformy.
A kto chce zostać na 50 MHz to niech zostanie i dalej się bawi. Ją uważam że ten projekt jest o niebo lepszy od Amigi typu Cloanto czy Amikit..
Dokładnie, jeśli są możliwe takie prędkości na emulacji udającej nigdy niewyprodukowane 68k to nie tylko VLC ale sporo innego softu może ktoś zdolny przekompiluje, np jakiś komunikator, browser, a i jest przecież GIMP czy Blender o Open Oficach nie mówiąc....
Ja by wręcz zaczął kampanię netową do powrotu na klasyczną dopaloną Ami pod hasłami:
- systemy virus/mailware free
- spy free
- niekompatybilny z invvigilacją...
To mogą być plusy w dzisiejszych czasach!
Ostatnia aktualizacja: 05.02.2016 17:44:32 przez xtro
05.02.2016 18:11
[#125]
Re: RTG i Vampire 600 V2
@xtro, post #124
Linuks też spełnia te warunki. I choćby przyszło tysiąc Gunnarów i każdy wypiłby tysiąc browarów i choćby nie wiem jak się wytężał... to GIMP, Blender, komunikator, browser czy OpenOffice będą na Linuksie i budżetowym x86_64 działać znacznie lepiej niż na rdzeniu Apollo. I nie trzeba ich przekompilowywać.
05.02.2016 19:25
[#129]
Re: RTG i Vampire 600 V2
@Krashan, post #115
swiete slowa, tez mam nadzieje, ze jednak nie pojda ta droga
ostatecznie wyjdzie na to, ze jak ktos ma swoja 060, to i tak bedzie MUSIAL kupic v2 zeby moc odpalic dedykowany soft na pseudo 68k..
jakos nie wierze w rozwijanie dwoch wersji. a juz sie cieszylem na prawdziwy zamiennik karty turbo do klasyka, a tu takie jaja z ta kompatybilnoscia sa w planie..
--
zeby uruchumoic gimpa czy inny rozbudowany open source to nie wystarczy skompilowac samego programu, przeciez to sa kombajny korzystajace z masy bibliotek.. dazmy do uzyskania aktualnej przegladarki to wtedy bedzie mozna mowic, ze cos dogonilismy - przeciez teraz juz wszystko jest na web'a..
ostatecznie wyjdzie na to, ze jak ktos ma swoja 060, to i tak bedzie MUSIAL kupic v2 zeby moc odpalic dedykowany soft na pseudo 68k..
jakos nie wierze w rozwijanie dwoch wersji. a juz sie cieszylem na prawdziwy zamiennik karty turbo do klasyka, a tu takie jaja z ta kompatybilnoscia sa w planie..
--
zeby uruchumoic gimpa czy inny rozbudowany open source to nie wystarczy skompilowac samego programu, przeciez to sa kombajny korzystajace z masy bibliotek.. dazmy do uzyskania aktualnej przegladarki to wtedy bedzie mozna mowic, ze cos dogonilismy - przeciez teraz juz wszystko jest na web'a..
05.02.2016 19:35
[#130]
Re: RTG i Vampire 600 V2
@pisklak, post #116
No cóż "zwykłe" rozkazy 68k w znakomitej większości wykonują się w 1 takcie zegara, chyba szybciej to się nie da.
Da się. Zamiast tracić zasoby układu na 64 bity i cuda na kiju, można zastosować przy tej samej cenie układ o mniejszej pojemności, ale za to szybciej taktowany.
Da się. Zamiast tracić zasoby układu na 64 bity i cuda na kiju, można zastosować przy tej samej cenie układ o mniejszej pojemności, ale za to szybciej taktowany.
05.02.2016 19:54
[#131]
Re: RTG i Vampire 600 V2
@juen, post #129
Ale gdzie tu widzisz problem?
To tak jakby 68020, nie bylo 68k, bo ma wiecej instrukcji i nowe tryby niz 68000.
Na razie Apollo ma chyba wszystkie instrukcje 68040, a ze bedzie mialo ich wiecej to jest zaleta a nie wada. Wszystkie programy dzialajace od 68000 do 68060 (bez FPU i MMU) powinny dzialac na Apollo, o ile nie bedzie problemem tym, ze procesor jest za szybki a autor programu tego nie przewidzial. Jak ktos bedzie chcial to napisze program wykorzystujacy nowe instrukcje Apollo i wtedy on nie zadziala na innych 68k bez trapowania, tak samo jak obecnie kto chce ten pisze sobie program na 68020, czy 68040 i nie przejmuje sie wcale tym, ze nie zadziala on na wczesniejszych wersjach 68k. Dla mnie to jest teraz tylko marudzenie do tego bezsensowne. Problem byl jakies 1.5 roku temu, gdy Gunnar chcial wstawic nowe instrukcje w miejsce istniejacych opcodow, tak samo jak w miejsce Aline, ale skoro emulator Maca dziala to zrezygnowal z tych niemadrych pomyslow tak samo jak z zewnetrznej emulacji instrukcji via trap. Zreszta jest o tym caly watek na EAB, wystarczy poszukac.
To tak jakby 68020, nie bylo 68k, bo ma wiecej instrukcji i nowe tryby niz 68000.
Na razie Apollo ma chyba wszystkie instrukcje 68040, a ze bedzie mialo ich wiecej to jest zaleta a nie wada. Wszystkie programy dzialajace od 68000 do 68060 (bez FPU i MMU) powinny dzialac na Apollo, o ile nie bedzie problemem tym, ze procesor jest za szybki a autor programu tego nie przewidzial. Jak ktos bedzie chcial to napisze program wykorzystujacy nowe instrukcje Apollo i wtedy on nie zadziala na innych 68k bez trapowania, tak samo jak obecnie kto chce ten pisze sobie program na 68020, czy 68040 i nie przejmuje sie wcale tym, ze nie zadziala on na wczesniejszych wersjach 68k. Dla mnie to jest teraz tylko marudzenie do tego bezsensowne. Problem byl jakies 1.5 roku temu, gdy Gunnar chcial wstawic nowe instrukcje w miejsce istniejacych opcodow, tak samo jak w miejsce Aline, ale skoro emulator Maca dziala to zrezygnowal z tych niemadrych pomyslow tak samo jak z zewnetrznej emulacji instrukcji via trap. Zreszta jest o tym caly watek na EAB, wystarczy poszukac.
05.02.2016 20:09
[#133]
Re: RTG i Vampire 600 V2
@strim_, post #120
Witam !
Właśnie wróciłem do domu z dwoma browcami co mają nadruk "super mocne" więc być może i komentarze będą "mocne" ;)
Cieszy mnie że toczy się dyskusja. I tak odnośnie komentarza użytkownika strim_ - masz naprawdę DUŻO racji. Muszę przyznać że dokumentacja CPU w tej chwili jest słabą stroną projektu którego najmocniejszą stroną jest właśnie ten CPU. Wynika to oczywiście z faktu że cały czas prowadzone sa prace udoskonalające Apollo, chociaż większość rzeczy powinna w tej chwili już pozostac bez zmian. W każdym razie większość najważniejszych rzeczy. Stąd apel do zainteresowanych koderów - jakiej informacji dokładnie oczekujecie i w jakiej formie ?
Jak myślę będę w stanie "przymusić" Gunnara do przyłożenia sie do dokumentacji wystarczającej do prób optymalizacji kodu pod Apollo w przystępnej i zrozumiałej formie. Nie samym CPU programista/projektant żyje...
Dzięki za ten post I mam nadzieję że sytuacja ulegnie wkrótce poprawie.
Właśnie wróciłem do domu z dwoma browcami co mają nadruk "super mocne" więc być może i komentarze będą "mocne" ;)
Cieszy mnie że toczy się dyskusja. I tak odnośnie komentarza użytkownika strim_ - masz naprawdę DUŻO racji. Muszę przyznać że dokumentacja CPU w tej chwili jest słabą stroną projektu którego najmocniejszą stroną jest właśnie ten CPU. Wynika to oczywiście z faktu że cały czas prowadzone sa prace udoskonalające Apollo, chociaż większość rzeczy powinna w tej chwili już pozostac bez zmian. W każdym razie większość najważniejszych rzeczy. Stąd apel do zainteresowanych koderów - jakiej informacji dokładnie oczekujecie i w jakiej formie ?
Jak myślę będę w stanie "przymusić" Gunnara do przyłożenia sie do dokumentacji wystarczającej do prób optymalizacji kodu pod Apollo w przystępnej i zrozumiałej formie. Nie samym CPU programista/projektant żyje...
Dzięki za ten post I mam nadzieję że sytuacja ulegnie wkrótce poprawie.
05.02.2016 20:18
[#134]
Re: RTG i Vampire 600 V2
@juen, post #129
Hmm..... naprawdę ktoś będzie MUSIAŁ kupić Vampira ? A to juz Apollo zapomniał jak sie wykonuje zwykły kod 020 ? No cóż jeśli naprawdę ktoś bardzo lubi 030 to myślę że na Apollo to też przejdzie ;)
Same dodatki czy rozszerzenia są opcjonalne - naprawdę nikt z nich nie musi korzystać jeśli nie chce. A jak sam powiedziałeś dedykowany soft jest... dedykowany ?
Czy Pentium MMX był naprawdę "niekomaptybilny" ? Naprawdę jeśli chcesz zobaczyć nowe oprogramowanie działające pod 020-060 i Apollo nie widze wiekszego problemu. Chociaż czasami znajdzie się program dedykowany pod Apollo, ale czy to znaczy że naprawdę nie mamy już teraz programów co najmniej zalecanych pod 040/060 ?
Pozdrawiam - pisklak
Same dodatki czy rozszerzenia są opcjonalne - naprawdę nikt z nich nie musi korzystać jeśli nie chce. A jak sam powiedziałeś dedykowany soft jest... dedykowany ?
Czy Pentium MMX był naprawdę "niekomaptybilny" ? Naprawdę jeśli chcesz zobaczyć nowe oprogramowanie działające pod 020-060 i Apollo nie widze wiekszego problemu. Chociaż czasami znajdzie się program dedykowany pod Apollo, ale czy to znaczy że naprawdę nie mamy już teraz programów co najmniej zalecanych pod 040/060 ?
Pozdrawiam - pisklak
05.02.2016 20:23
[#135]
Re: RTG i Vampire 600 V2
@Don_Adan, post #132
Nie, nie myli. Optymalizacja podczas syntezy układu logicznego może iść w:
a) największą prędkość (najmniejsze opóźnienia) - kosztem pojemności
b) największe upakowanie logiki (gdzie wykorzystujemy maksymalnie dużo elementów logicznych) - ale kosztem prędkości. To jak dwie krzywe przecinające się w optimum (czyt. jeśli zbyt uprościmy logikę to przyrost prędkości nie zrekompensuje spadku wydajności, jeśli przekombinujemy z logiką to prędkość spadnie na tyle, że nawet większa wydajność na takt nie pozwoli na osiągnięcie szczytu). Tutaj muszę powiedzieć, że mikrofuzje instrukcji byłyby o tyle lepsze, że działałyby w każdej aplikacji przy zaistnieniu odpowiednich warunków (czyli także z istniejącym kodem) - coś czego żadne 64b nie dadzą. Dodatkowo coś bardziej sensownego to byłyby nawet 64b ale SIMD (w trybie adresowania 32b) - wystarczyłoby wtedy przepisać biblioteki matematyczne i soft z nich korzystający automatycznie skorzysta z nowych instrukcji.
a) największą prędkość (najmniejsze opóźnienia) - kosztem pojemności
b) największe upakowanie logiki (gdzie wykorzystujemy maksymalnie dużo elementów logicznych) - ale kosztem prędkości. To jak dwie krzywe przecinające się w optimum (czyt. jeśli zbyt uprościmy logikę to przyrost prędkości nie zrekompensuje spadku wydajności, jeśli przekombinujemy z logiką to prędkość spadnie na tyle, że nawet większa wydajność na takt nie pozwoli na osiągnięcie szczytu). Tutaj muszę powiedzieć, że mikrofuzje instrukcji byłyby o tyle lepsze, że działałyby w każdej aplikacji przy zaistnieniu odpowiednich warunków (czyli także z istniejącym kodem) - coś czego żadne 64b nie dadzą. Dodatkowo coś bardziej sensownego to byłyby nawet 64b ale SIMD (w trybie adresowania 32b) - wystarczyłoby wtedy przepisać biblioteki matematyczne i soft z nich korzystający automatycznie skorzysta z nowych instrukcji.
05.02.2016 20:38
[#137]
Re: RTG i Vampire 600 V2
@Krashan, post #130
W teorii wszystko "da się". Ale oczywiście masz rację. Na przykład w tej chwil Vampirka wysyłana do ludzi ma "silver core" który ma taktowanie 11x7.09 Mhz. Co nie znaczy że następne wersje nie będą szybciej taktowane. Druga sprawa to jest kontroler pamięci. I tak na przykład demo AWin na silver core w 640x480x8 w tej chwili wyciaga jakieś 50 FPS w okienku na "V3" - to jest na Vapmpirce V2-128. Ale z nowszymi wsadami do juz bliżej do 70 FPS dochodzi ponieważ Gunnae and Ceaich wzieli sie za optymalizację kontrolera pamięci. Trzecia sprawa to pozostała jeszcze optymalzacja pod względem prędkości wsadu FPGA - jak na razie najwyzszym taktowaniem które działa stabilnie na niektórych Vampirkach ( tych które mają szczęście wylosować prawdziwy Grade6 układ FPGA) jest x14. Po optymalizacji wartość ta może się zwiększyć. No i następna sprawa to te "nieszczęsne rozszerzenia" .. no ale przecie z to niekompatybilne jest ;) .
W tej chwili istnieje możliwość optymalizacji normalnego kodu żeby po prostu działał szybciej z Apollo, bez użycia żadnych nowych rozkazów. Naprawdę nawet "stary" kod może działać szybciej jeśli zostanie lekko zmodyfikowany. Tak było w przypadku 060 i tak jest też z Apollo.
Pozdrawiam - pisklak
W tej chwili istnieje możliwość optymalizacji normalnego kodu żeby po prostu działał szybciej z Apollo, bez użycia żadnych nowych rozkazów. Naprawdę nawet "stary" kod może działać szybciej jeśli zostanie lekko zmodyfikowany. Tak było w przypadku 060 i tak jest też z Apollo.
Pozdrawiam - pisklak
05.02.2016 20:56
[#139]
Re: RTG i Vampire 600 V2
@Don_Adan, post #131
Osobiście zgadzam się z Twoim punktem widzenia.
Jak sądzę mogę Cie nazywać doświadczonym programistą 68K :) zresztą jak wielu innnych tutaj obecnych. A skoro już się zgodziłem że dokumentacja Apollo może być niewystarczająca... czy mógłbyś dokładnie wskazać jakiego rodzaju informacji i w jakiej formie potrzebujesz żeby "ogarniać sprawę" ? Obiecuję przycisnąć Gunnara żeby się zabrał do lepszej dokumentacji...
No i ciągle czekam na chętnych którzy chca zoptymalizować RIVĘ.... jakby co to chyba mogę służyć Vampirką. Niestety "starą" wersją to jest V2-64 developer edition ( tylko 64 Mb pamięci i mniejsza szyna ram) ale myślę że chetnie bym ją oddał w duzo lepsze ręce niż moje. Ja jeszcze niedawno nie znałem ani jednego rozkazu 68k. Teraz mogę napisać naprawdę proste programy jak np. efekt ognia który zresztą w moim wykonaniu jest.... powiedzmy że nieoptymalny ;)
Jak sądzę mogę Cie nazywać doświadczonym programistą 68K :) zresztą jak wielu innnych tutaj obecnych. A skoro już się zgodziłem że dokumentacja Apollo może być niewystarczająca... czy mógłbyś dokładnie wskazać jakiego rodzaju informacji i w jakiej formie potrzebujesz żeby "ogarniać sprawę" ? Obiecuję przycisnąć Gunnara żeby się zabrał do lepszej dokumentacji...
No i ciągle czekam na chętnych którzy chca zoptymalizować RIVĘ.... jakby co to chyba mogę służyć Vampirką. Niestety "starą" wersją to jest V2-64 developer edition ( tylko 64 Mb pamięci i mniejsza szyna ram) ale myślę że chetnie bym ją oddał w duzo lepsze ręce niż moje. Ja jeszcze niedawno nie znałem ani jednego rozkazu 68k. Teraz mogę napisać naprawdę proste programy jak np. efekt ognia który zresztą w moim wykonaniu jest.... powiedzmy że nieoptymalny ;)
05.02.2016 20:57
[#140]
Re: RTG i Vampire 600 V2
@abcdef, post #135
Myli sie i ty tez. Ja sledze procesor Gunnara od juz chyba 5 lat, byl nazywany 68050, 68070 a ostatnio Apollo. W zaleznosci od tego na jakim etapie rozwoju ten procesor byl. Dla mnie i innych koderow jak meynaf problemem bylo to ze mialo w nim nie byc wielu instrukcji, taki kastrat. Mi chodzilo o movep a Philowi o bitfields i jakies jeszcze inne instrukcje. Dodanie ich mialo powodowac spowolnienie dzialania calego procesora. Gunnar chcial je trapowac (watek na EAB) , nie wyjasniajac dlaczego sa problemem. Dopiero niedawno zrozumialem, w czym byl problem, zarowno movep.l jak i niektore bitfieldy to sa operacje na wiecej niz 32 bitach, movep.l operuje na 64 bitach. Tak wiec bez wewnetrznych 64 bitow nie byloby chyba mozliwe zaimplementowanie tych instrukcji bez spowolnienia calego Apollo. Dzieki temu ze procesor dziala na 64 bitach jest mozliwe wykonanie movep czy bitfields w 1 cyklu. Kto chce niech sobie sprawdzi ile takie instrukcje zajmuja czasu na innych 68k. Gunnar osiagnal taka sama szybkosc dla 64 bitow jak bylo dla 32 bitow. Wiec nie ma tu mowy o zadnym spowolnieniu w dzialaniu Apollo, bez roznicy czy 32 czy 64 bit. Do tego bardzo szybkie bitfields i movep daja zupelnie nowe mozliwosci. Co do pojemnosci FPGA to nawet w Cyclone III z Vampire 2 jest jego jeszcze mnostwo, tez jest watek na EAB, ile co zajmuje.
Ostatnia aktualizacja: 05.02.2016 21:02:12 przez Don_Adan
Ostatnia aktualizacja: 05.02.2016 21:02:12 przez Don_Adan
05.02.2016 21:00
[#141]
Re: RTG i Vampire 600 V2
@xtro, post #138
Nie jak najbardziej NIE . Wiesz FPGA ma tą zaletę że naprawdę łatwo jest załadować nowy wsad=nowy procek. A jak dzizłał będzie softwareowy updater który właśnie jest w opracowaniu to nie potrzebny Ci będzie ani USB Blaster ani PC z Quartussem. Naprawdę updrade wsady powinno byc "szybkie i bezbolesne"
Podzrawiam - pisklak
Podzrawiam - pisklak
05.02.2016 21:30
[#142]
Re: RTG i Vampire 600 V2
@Don_Adan, post #140
Zapewne dobrym wyjaśnieniem jest.... Phoenix i malutka FPGA w Vampire1. Dlatego Gunnar chciał niektóre rzeczy "masakrować" ... bo po prostu się nie mieściły do malutkiej FPGA. Teraz gdy jest C3 z 40K LE spokojnie to wszystko się mieści i jeszcze sporo miejsca zostało. Jak na razie to układ jest zapełniony w jakichś może 60%. Po dodaniu FPU i i tego kozackiego Vectora to powinno jeszcze nawet troszkę zostać.
A tak się zapytam - gdybyś miał info o różnicach pomiędzy starym 68k i Apollo to napisałbyś np. texturemappera pod niego ? Tak w ramach swoistej rozgrzewki. Myślę że Gunnar chętnie skomentował by Twój kod. I zapewne w końcu byście się lepiej zrozumieli - jak programista z projektantem CPU ;)
A tak się zapytam - gdybyś miał info o różnicach pomiędzy starym 68k i Apollo to napisałbyś np. texturemappera pod niego ? Tak w ramach swoistej rozgrzewki. Myślę że Gunnar chętnie skomentował by Twój kod. I zapewne w końcu byście się lepiej zrozumieli - jak programista z projektantem CPU ;)
05.02.2016 21:37
[#143]
Re: RTG i Vampire 600 V2
@pisklak, post #139
Na poczatek to wazne sa wedlug mnie nastepujace informacje.
1. Czy jakies instrukcje 68040 CPU nie sa jeszcze w pelni zaimplementowane. Jesli nie sa, to jakie.
2. Timingi instrukcji, chodzi o te ktore sa najwolniejsze i ile cykli zajmuja, no chyba ze wszystkie sa wykonywane w 1 cyklu.
3. Przyklady prawidlowego wykorzystania fuzji itp, tak zeby jak najwiecej instrukcji bylo wykonywanych w jednym cyklu procesora. Czyli chodzi o kolejnosc instrukcji w kodzie.
Ja nie mam A600, wiec nie moge testowac na biezaco. Ale pewnie jest paru chetnych koderow do testow.
1. Czy jakies instrukcje 68040 CPU nie sa jeszcze w pelni zaimplementowane. Jesli nie sa, to jakie.
2. Timingi instrukcji, chodzi o te ktore sa najwolniejsze i ile cykli zajmuja, no chyba ze wszystkie sa wykonywane w 1 cyklu.
3. Przyklady prawidlowego wykorzystania fuzji itp, tak zeby jak najwiecej instrukcji bylo wykonywanych w jednym cyklu procesora. Czyli chodzi o kolejnosc instrukcji w kodzie.
Ja nie mam A600, wiec nie moge testowac na biezaco. Ale pewnie jest paru chetnych koderow do testow.
05.02.2016 21:47
[#144]
Re: RTG i Vampire 600 V2
@Don_Adan, post #143
Wszystko wietnie tylko ze.... czy ja naprawdę muszę być pośrednikiem ? Cóż chyba w dzisiejszych czasach ludzie zapomnieli że istnieje coś takiego jak IRC. Z całym szacunkiem do Ciebie i innych ale naprawdę lepiej by się Tobie I Gunnarowi rozmawiało "na żywo". Wiem że być może to wymaga odrobinę wysiłku... no ale czy warto to na to pytanie musisz sobie Ty a także inni sami odpowiedzieć. W każdy razie ja się deklaruję jako "kiepski pomost". Jeślii to jest jedyna droga. A jak już wspomniałem postaram sie nakłonic Gunnara do wypuszczeni ajakiejs sensownej dokumentacji....
Pozdrawiam - pisklak
Pozdrawiam - pisklak
05.02.2016 22:03
[#145]
Re: RTG i Vampire 600 V2
@pisklak, post #144
Rozmowa, rozmowa, trzeba dobrze znac angielski. No i czym innym sa informacje dla jednej osoby a czym innym dla wszystkich, inni tez moga byc zainteresowani. Po co sie powtarzac, jak jest jakies oficjalne info dostepne dla wszystkich, ktore zawsze mozna tez poprawic czy uzupelnic to jest lepiej wedlug mnie. Ale Gunnara jest ciezko przekonac, co widac w ponizszym linku, wiec lepiej jak ty go pomeczysz.
Tutaj jest ten stary watek z Gunnarem, prawie 2 lata minely, jak chcialem zeby byly wszystkie instrukcje 68040 i 68882 w Apollo:
http://eab.abime.net/showthread.php?t=73297
Tutaj jest ten stary watek z Gunnarem, prawie 2 lata minely, jak chcialem zeby byly wszystkie instrukcje 68040 i 68882 w Apollo:
http://eab.abime.net/showthread.php?t=73297
05.02.2016 22:11
[#146]
Re: RTG i Vampire 600 V2
@Don_Adan, post #145
Pomęczyć to go pomęczę... no chyba że mnie z Teamu wywali :P
A tak na bardziej serio - Gunnar jednak zyskuje przy bliższym poznaniu. Możesz mi wierzyć bądź nie. A co do tego angielskiego.... Ha Ty naprawdę nie widziałeś moich IRCowych "angielskich wyczynów". Zapeniam Cię że jesli piszesz wystarczająco zrozumiale nawet bardzo nieperfekcyjnym angielskim zostaniesz dobrze przyjęty. Wiem coś o tym bo sam jestem tego dobrym przykładem. No i zawsze pozostaje "uniwersalny język programisty" czyli kod :)
Naprawdę serdecznie zapraszam na IRCa i forum Apollo.
A tak na bardziej serio - Gunnar jednak zyskuje przy bliższym poznaniu. Możesz mi wierzyć bądź nie. A co do tego angielskiego.... Ha Ty naprawdę nie widziałeś moich IRCowych "angielskich wyczynów". Zapeniam Cię że jesli piszesz wystarczająco zrozumiale nawet bardzo nieperfekcyjnym angielskim zostaniesz dobrze przyjęty. Wiem coś o tym bo sam jestem tego dobrym przykładem. No i zawsze pozostaje "uniwersalny język programisty" czyli kod :)
Naprawdę serdecznie zapraszam na IRCa i forum Apollo.
05.02.2016 22:22
[#147]
Re: RTG i Vampire 600 V2
@pisklak, post #133
Muszę przyznać że dokumentacja CPU w tej chwili jest słabą stroną projektu którego najmocniejszą stroną jest właśnie ten CPU.
Nie tyle jest słabą stroną, ile wcale jej nie ma.
Stąd apel do zainteresowanych koderów - jakiej informacji dokładnie oczekujecie i w jakiej formie ?
Potrzebne jest to samo, co Motorola umieszczała w dokumentacji "User's Manual" danego procesora. Oczywiście z pominięciem części czysto sprzętowej bo to nie ma zastosowania w FPGA.
Przykład dla 68060.
Poza tym odnośnie "pośredniczenia" Twojego. Tu nie chodzi o to, że masz być pośrednikiem, tylko że brakuje zupełnie podstawowej rzeczy, aby ktokolwiek mógł zacząć cokolwiek robić z Apollo od strony programowej. Nie rozumiem jak nikt w teamie Apollo nie zauważył tego oczywistego braku.
Ostatnia aktualizacja: 05.02.2016 22:25:04 przez strim_
05.02.2016 22:26
[#148]
Re: RTG i Vampire 600 V2
@abcdef, post #135
Mikrofuzje to naprawdę fajna rzecz. Tylko jak zapewne wiesz maja taką tyci wadę podobną do np. "drugiej pipy" w 060, czyli nie zawsze "da się". Nie zawsze da się zastosować fuzję tam gdzie akurat by wypadało tak samo jak nie zawsze da się napisać kod który jest wykonywany na 2 (lub więcej) potokach. A nowe instrukcje/rozszerzenia "da się". Czy naprawadę Was koderów dziwi ze Gunnar chce dodać nowe rozkazy ?
05.02.2016 22:33
[#149]
Re: RTG i Vampire 600 V2
@strim_, post #147
Cóż..... chyba nie po raz pierwszy w historii okazało się ze inżynierowie niekoniecznie są "geniuszami dokumentacji". I jak sądzę z podobnymi problemami spotyka się wiele projektów.
Co nie znaczy że nie masz racji. Dokumentacja musi powstać w formie "nieco lepszej" niż wpis na forum bądź rozmowa na IRCu. No myslę że tu jednak mam jakieś "pole do popisu" w sensie tym że mogę próbować "przymusić" Gunnara do zrobienia czegoś sensownego. No a jeśli to nie wypali.... Będę być może podawał tu na forum wszelkie możliwe info być może ktoś to poskleja....
Co nie znaczy że nie masz racji. Dokumentacja musi powstać w formie "nieco lepszej" niż wpis na forum bądź rozmowa na IRCu. No myslę że tu jednak mam jakieś "pole do popisu" w sensie tym że mogę próbować "przymusić" Gunnara do zrobienia czegoś sensownego. No a jeśli to nie wypali.... Będę być może podawał tu na forum wszelkie możliwe info być może ktoś to poskleja....
05.02.2016 23:12
[#150]
Re: RTG i Vampire 600 V2
@Don_Adan, post #143
[21:41:09] <BigGun> all instructions are there ..
[21:41:16] <BigGun> but
[21:41:23] <BigGun> BF need little more tests.
[21:41:29] <BigGun> and missing is
[21:41:35] <BigGun> CMP2 and CHK2
[21:41:43] <BigGun> all other are in
[21:42:12] <BigGun> sloest is DIV
[21:42:35] <BigGun> 33 cycle for 64bit div
[21:42:53] <BigGun> most normal instruction take 0.5 cycle
[21:43:35] <BigGun> our timing is very similar to 68060, at least as fast as 060, sometimes faster than 68060
[21:43:42] <flype> how costly is a full movem.l in stack ?
[21:44:21] <BigGun> movem one clock per saved reg
[21:44:54] <BigGun> mul 64bit takes 2 clock
[21:46:38] <BigGun> all clear?
[21:47:24] <BigGun> with FUSING basically the rule is MOVE+OPP = fused
Oczywiście pomijając ( na razie) instrukcje FPU i MMU.
OK wiem iż to jest dokładnie taki rodzaj informacji jakiego NIE CHCECIE panowie. Lecz.... powiedzmy że to jest taki malutki początek.... na dobranoc :)
Pozdrawiam - pisklak
[21:41:16] <BigGun> but
[21:41:23] <BigGun> BF need little more tests.
[21:41:29] <BigGun> and missing is
[21:41:35] <BigGun> CMP2 and CHK2
[21:41:43] <BigGun> all other are in
[21:42:12] <BigGun> sloest is DIV
[21:42:35] <BigGun> 33 cycle for 64bit div
[21:42:53] <BigGun> most normal instruction take 0.5 cycle
[21:43:35] <BigGun> our timing is very similar to 68060, at least as fast as 060, sometimes faster than 68060
[21:43:42] <flype> how costly is a full movem.l in stack ?
[21:44:21] <BigGun> movem one clock per saved reg
[21:44:54] <BigGun> mul 64bit takes 2 clock
[21:46:38] <BigGun> all clear?
[21:47:24] <BigGun> with FUSING basically the rule is MOVE+OPP = fused
Oczywiście pomijając ( na razie) instrukcje FPU i MMU.
OK wiem iż to jest dokładnie taki rodzaj informacji jakiego NIE CHCECIE panowie. Lecz.... powiedzmy że to jest taki malutki początek.... na dobranoc :)
Pozdrawiam - pisklak