Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Strony Poprzednia 1 … 4 5 6 7 8 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
To przedstaw cokolwiek co demonstruje ten problem, bo my twierdzimy że go nie ma.
Proszę bardzo
http://dev-docs.atariforge.org/files/CO … V2_AES.pdf
Strona 164 przykładowy program dialog1.c jest wywoływanie funkcji z systemu,
skompiluj pod x86 żeby działało okienka niech się pokazują na emulowanym freemincie.
Skoro problemu nie ma to powinno to być proste.
Adam Klobukowski napisał/a:To przedstaw cokolwiek co demonstruje ten problem, bo my twierdzimy że go nie ma.
Proszę bardzo
http://dev-docs.atariforge.org/files/CO … V2_AES.pdf
Strona 164 przykładowy program dialog1.c jest wywoływanie funkcji z systemu,
skompiluj pod x86 żeby działało okienka niech się pokazują na emulowanym freemincie.
Skoro problemu nie ma to powinno to być proste.
Ale po co? AranyM z JITem robi to cały czas. Masz coś lepszego? Bo nadal nie ma problemu.
Ja twierdzę że się nie da bez dużego nakładu pracy.
Mieszasz pojęcia. Skompilowanie i uruchomienie dowolnego programu na dowolną-obcą platformę, gdy się nie ma gotowego środowiska emulującego jedną platformę na drugiej, nawet gdy obie mają tę samą indiańskość, wymaga dużego nakładu pracy i czasu, którego tu nikt nie zamierza na to poświęcać.
Natomiast wymiana danych pomiędzy pomiędzy x86 a m68k (czy ogólniej pomiędzy procesorem LE a BE) to żaden problem, odbywa się to przypuszczalnie miliard razy w ciągu doby, ilekroć ktoś przełoży kartę CF z peceta do starego maka (albo odwrotnie) w celu odczytania lub zapisania pliku.
Tyle razy wspominany przez Ciebie freemint to robi w sterowniku obsługi FAT. Nawet na m68k ta konwersja to nic specjalnego, dla 16-bit int to będzie 1 rozkaz (rol.w #8,dn - chyba 8 cykli na 68030, nie pamiętam już), a dla 32-bit int - 3 rozkazy: rol/swap/rol.
10 takich konwersji to 20 sekwencji takich rozkazów (bo to działanie jest komplementarne: odczyt - konwersja - obliczenia - konwersja - zapis). Niech sekwencja zajmie 20 cykli. 20x20 = 400 cykli. Dla procesora pracującego z częstotliwością 16 MHz działanie zatytułowane tutaj "obliczeniem" (x10) wydłuży się o 1/40000 (jedną czterdziestotysięczną) sekundy. Nie masz szans tego zauważyć.
EDIT:
wymiana różnych skomplikowanych danych między różnymi procesorami.
A jakimiż to "skomplikowanymi danymi" posługuje się wg Ciebie program ze strony 164 zacytowanego podręcznika? Tam są tylko 32-bitowe wskaźniki oraz 8-, 16- i 32-bitowe integery.
Ostatnio edytowany przez drac030 (2015-09-27 19:40:29)
Ale po co? AranyM z JITem robi to cały czas. Masz coś lepszego? Bo nadal nie ma problemu.
Skoro twierdzisz że wymiana danych nie jest problemem, to nie powinno ci to sprawić kłopotu.
To co pokażesz że nie ma problemu z wymianą danych i skompilujesz to pod x86?
skompiluj pod x86 żeby działało okienka niech się pokazują na emulowanym freemincie.
A może Ty szybciutko skompiluj ten przykładowy program w C z archiwów Amigi http://aminet.net/util/wb/AmigaEyes1.1a.lha na swoim MiniMac i pokaż, że działa bez najmniejszego problemu dzięki temu, że masz na pokładzie PowerPC.
Czysty kod w C, żadnych finezji....po prostu "brać i kompilować"....najlepiej wgraj na YouTube efekty....czekamy 15 minut....toż to prosta operacja jest.
Ostatnio edytowany przez BartoszP (2015-09-27 19:47:37)
Mieszasz pojęcia. Skompilowanie i uruchomienie dowolnego programu na dowolną-obcą platformę, gdy się nie ma gotowego środowiska emulującego jedną platformę na drugiej, nawet gdy obie mają tę samą indiańskość, wymaga dużego nakładu pracy i czasu, którego tu nikt nie zamierza na to poświęcać.
Nie zrozumiałeś. Dlatego właśnie powerpc jest lepsze że możesz bez problemu użyć starego 68k kodu w nowym sofcie powerpc. A da się bo i 68k i powerpc są procesorami big endian.
Skoro twierdzisz że to samo dasz radę zrobić na x86 to pokaż że się da i zrób.
To nie "powerpc jest lepsze" tylko masz gotowy emulator Amigi na PPC. Załatw mi taki emulator Atari na x86, to ci zrobię, jak ładnie poprosisz.
To nie "powerpc jest lepsze" tylko masz gotowy emulator Amigi na PPC. Załatw mi taki emulator Atari na x86, to ci zrobię, jak ładnie poprosisz.
Przecież masz freeminta, masz ARAnyM i twierdzisz że na x86 też się da.
Pokaż że się da i zrób.
Nie lubię Aranyma i nie poprosiłeś wystarczająco ładnie. A w zasadzie wcale.
Ostatnio edytowany przez drac030 (2015-09-27 20:08:50)
Pan swinkamor12 po prostu myli emulację procesora i emulację sprzętu w którym działa dany emulowany procesor a na dodatek jeszcze nie odróżnia tego, że w tym zestawie dwóch emulatorów dołożony jest jeszcze system operacyjny napisany specjalnie dla danego sprzętu załatwiający obsługę API czyli w ogóle możliwość uruchamiania oryginalnych programów.....
Ale co to za różnica....ważne, że big-endian......
A może Pan swinkamor12 po prostu pobierze źródła HATARI http://hg.tuxfamily.org/mercurialroot/hatari/hatari, skompiluje pod PowerPC i będzie miał to czego pragnie bo przecież FreeMINTa też ma. Ja dlatego właśnie nie rozumiem o co temu EKSPERTOWI z takim doświadczeniem chodzi.
swinkamor12 napisał/a:skompiluj pod x86 żeby działało okienka niech się pokazują na emulowanym freemincie.
A może Ty szybciutko skompiluj ten przykładowy program w C z archiwów Amigi http://aminet.net/util/wb/AmigaEyes1.1a.lha na swoim MiniMac i pokaż, że działa bez najmniejszego problemu dzięki temu, że masz na pokładzie PowerPC.
Czysty kod w C, żadnych finezji....po prostu "brać i kompilować"....najlepiej wgraj na YouTube efekty....czekamy 15 minut....toż to prosta operacja jest.
Obawiam się, że sie zbuduje i odpali…
Przez to, że w MorphOSie jest Trance (JIT m68k → PPC), a wywołania programów Workbencha (typu otwarcie ekranu czy okna dla intuition.library, lub pliku bądź folderu dla dos.library) są konwertowane w locie na MorphOS API, jak pisałem na początku.
Więc jak chcecie dopiec koledze to okej, popieram, ale najpierw sami zrozumcie jak działa "system wroga" czyli MorphOS.
Nie lubię Aranyma i nie poprosiłeś wystarczająco ładnie. A w zasadzie wcale.
Czyli jednak na x86 się nie da. Tylko że nie chcesz się przyznać że nie masz racji.
Da się, tylko nie spełniasz warunków :D
Przez to, że w MorphOSie jest Trance (JIT m68k → PPC), a wywołania programów Workbencha (typu otwarcie ekranu czy okna dla intuition.library, lub pliku bądź folderu dla dos.library) są konwertowane w locie na MorphOS API, jak pisałem na początku.
Ale zauważ, że to ewentualne zadziałanie nie jest zasługą konkretnego procesora tylko tysięcy linii kodu emulatorów, kompilatorów, bibliotek, które wykonują czarna robotę i ukrywają wszystkie szczegóły. Gdyby MorphOS był dostępny dla procesorów ARM, to mielibyśmy pienia o wyższości ARM nad x86,
Tak czy inaczej co stoi na przeszkodzie w skompilowaniu HATARI w tym środowisku i cieszeniem się FreeMINT ?
Nie do mnie pytanie, ja tylko poprawiam.
A co do samego MorphOSa, to po cichu niektórzy z Teamu pokątnie szeptają o przeskoku na architekturę x86_64 albo ARM z racji dostępności sprzętu.
Skrzypie: aby to co piszesz miało zadziałać tak jak piszesz, to wzmiankowany program musiałby zostać skompilowany do pliku wykonywalnego Amigi z procesorem 68K. Zapewne jakimś zabytkowym kompilatorem C. Jeśli skompilujesz go kompilatorem gcc dostępnym dla PowerPC ( jak widać było na przykładach zresztą dość starym bo z chyba 2005 roku ) to wygenerowany zostanie program natywny dla PPC.
Jak myślisz czy "endianess" ma wielkie znaczenie dla obliczeń tego typu gdzie i, xp, yp są zmiennymi typu SHORT i masz obliczenia zmiennoprzecinkowe ? Wskaźnik pixel wskazuje na zmienną typu UCHAR czyli co chwilę mamy wyjątki w dostępie do pamięci bajt po bajcie, efektywność spada....jakie ma znaczenie procesor ?
for (i = 0; i <= RESOL; i++)
{
x = (float)rx * sgn*dcos[i];
y = -(float)ry * sgn*dcos[RESOL-i];
xp = (int)(x+rEYE+0.5);
yp = (int)(y+yEYE+0.5);
Plot(EyeWnd, xp, yp, c);
*(pixel+SIZEWNDX*xp+yp) = c;
xp = (int)(-x+rEYE+0.5);
Plot(EyeWnd, xp, yp, c);
*(pixel+SIZEWNDX*xp+yp) = c;
}A to zasługuje na osobny post...cytat z bloga autora emulatora E-UAE w MorphOS i AmigaOS4...podkreślenia autora...
Further dreams
This project was set up specifically to implement JIT compiling for PowerPC processors, due to the current state of AmigaOS4 and MorphOS. Since the JIT compiling was already available for x86 it was never a goal for me to come up with a generic solution which supports multiple architectures.But more than 4 years passed since I started to think about it and lots of things have changed. Nowadays smart phones are standing tall, probably even more important than desktop computers. These are mostly running on ARM compatible processors, so PPC or x86 JIT implementations are completely useless for these devices.
When I had a few email rounds with Toni Wilen, maintainer of WinUAE, he complained about the x86 implementation and mentioned that it is completely outdated in the era of x64 architecture. Unfortunately, the ancient x86 implementation is so complicated and messy that nobody is brave enough to touch it. (This is why I started my own implementation instead of porting the x86 version.)
AmigaOS4 is running on PowerPCs, but let's be realistic: PowerPC is dead. (Or is it? Yes, it is at desktop computing.) Sooner or later AmigaOS4 will migrate to a new architecture probably.So, what is the bottom line of my ramblings? This JIT implementation was made for PowerPC, but it can be changed to support multiple processor architectures. I don't think that it would be too complicated, the majority of the code can be reused, it just needs some restructuring.
Odpuściłem ten wątek na parę dni no i teraz widzę że temat zszedł na jakieś mało istotne (dla mnie) amigowe tematy.
Dla mnie kluczowe pytanie jest czemu w ogóle brnąć w PowerPC a nie Intel czy ARM.
Bo JIT? Ten argument mnie nie przekonuje. Kompilacja 68k JIT jest dostępna na Intela od wielu lat w ARAnyM i WinUAE.
Wydajność? Jest w ogóle jakiś laptop z PowerPC który dogoni moją leciwą dwu-rdzeniową i5 2.4GHz?
Pomimo dużego sentymentu do PowerPC dla mnie ta technologia w klasie komputerów domowych jest martwa. Co innego konsole i stacje robocze - tam ma się ona na razie dobrze.
swinkamor12 może opublikuj jakieś benchmarki? Chętnie zobaczę co aktualnie emulacja 68k na PowerPC sobą reprezentuje.
Cyprian: Właśnie nawet na rynku serwerów i konsol jest to technologia wymierająca. PowerPC jest obecny PS3 i Xbox360 ale już w PS4 i XboxOne jest AMD64. Także to jest ślepy zaułek.
Jak rozumiem swinkamor12 mówi ciągle o przekompilowaniu za pomocą jakieś magicznego narzędzia kodu M68k na PowerPC. Jak zrozumiałem, jeśli ten kod wykorzystuje odwołania systemowe, to są one automatycznie przetwarzane na wywowałania funkcji w systemie. Oczywiście kod systemu jest natywnie napisany/skompilowany na PowerPC.
Może stąd wynika ta różnica w szybkości pomiędzy PowerPC a i7. Może gdyby cały system był skompilowany na i7, a nie był emulowany to i7 byłby jednak szybszy od PowerPC.
Jeśli chodzi o kompilowanie tego przykładu z książki to jestem prawie pewien, że bez problemu skompilowałby się na x86/AMD64/ARM. Nawet podejrzewam, że binarka m68k przekompilowałaby się na x86 bez problemów z BigEndian/LittleEndian. Stałoby się tak, w wypadku gdy system z którego wywołań by korzystała, byłby skompilowany natywnie na x86/AMD64/ARM (tak jak pewnie jest w przypadku AmigaOS czy MorphOS na PowerPC).
Dla mnie kluczowe pytanie jest czemu w ogóle brnąć w PowerPC a nie Intel czy ARM.
Fajna zabawka dla programistów.
Kilkadziesiąt razy szybsze od 68k, i wciąż big endian co znacznie zmniejsza nakład pracy na wymianę danych ze starym kodem 68k. Bardzo łatwe użycie starego kodu 68k np starych bibliotek 68k w nowym sofcie nie 68k.
Wydajność? Jest w ogóle jakiś laptop z PowerPC który dogoni moją leciwą dwu-rdzeniową i5 2.4GHz?
Jeśli chodzi o kod big endian to natywny kod na G4 jest parę razy szybszy niż emulowany big endian na i7.
Może stąd wynika ta różnica w szybkości pomiędzy PowerPC a i7. Może gdyby cały system był skompilowany na i7, a nie był emulowany to i7 byłby jednak szybszy od PowerPC.
Tylko że atari i amiga to nie Apple. 90% softu na Amigę i 99% softu na Atari nikt nigdy nie skompiluje na i7.
Bo to źródła zaginęły, albo jak są to w asm, albo w kompilatorze C sprzed 30 lat, itp itd.
Dlatego powerpc jest lepsze.
Jeśli chodzi o kod big endian to natywny kod na G4 jest parę razy szybszy niż emulowany big endian na i7.
Spacer jest zdrowszy niż oglądanie boksu w telewizji.
Tylko że atari i amiga to nie Apple. 90% softu na Amigę i 99% softu na Atari nikt nigdy nie skompiluje na i7.
Bo to źródła zaginęły, albo jak są to w asm, albo w kompilatorze C sprzed 30 lat, itp itd.
Dlatego powerpc jest lepsze.
A po co kompilować ? Co tracimy ?
Nawet Apple zrezygnowała z PowerPC na rzecz Intela. Ciekawe czemu ?
Ostatnio edytowany przez BartoszP (2015-09-28 17:54:18)
Przecież widać, że swinkamor12 wymyślił sobie na siłę powód, dla którego PPC jest najlepsze (rzekomy "nakład pracy" przy wymianie "skomplikowanych danych" ze starym kodem 68k), i że żaden argument, że jest inaczej, do niego nie dotrze; tak samo zresztą, jak to było przy jego poprzedniej fazie (kto zainteresowany, niech sobie znajdzie, a niektórzy pewnie nawet pamiętają).
Fajna zabawka dla programistów.
Kilkadziesiąt razy szybsze od 68k, i wciąż big endian co znacznie zmniejsza nakład pracy na wymianę danych ze starym kodem 68k. Bardzo łatwe użycie starego kodu 68k np starych bibliotek 68k w nowym sofcie nie 68k.
Kiladziesiąt razy szybsze niż 68k? Coś słabo coś z wydajnością PPC.
Na moim leciwy i5 Aranym JIT ma 24 400% wydajności STka.
Jednym klawiszem kompiluję i uruchamiam kod 68k. Mam do dyspozycji wiele emulatorów. To jest fajna zabawka dla programistów.
Jeśli chodzi o kod big endian to natywny kod na G4 jest parę razy szybszy niż emulowany big endian na i7.
Skąd masz te informacje? Zapodaj jakieś wiarygodne benchmarki.
@swinkamor12: Teraz już wiem że nie wiesz co mówisz i nie rozumiesz co się do Ciebie mówi :). Pewnie MorphOSa i AmigaOS 4 też nie mają źródeł i odpalają bezpośrednio na PowerPC ;P.
Strony Poprzednia 1 … 4 5 6 7 8 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.104 sekund, wykonano 12 zapytań ]