126

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.

127

swinkamor12 napisał/a:
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.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

128 Ostatnio edytowany przez drac030 (2015-09-27 19:40:29)

swinkamor12 napisał/a:

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:

swinkamor12 napisał/a:

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.

KMK
? HEX$(6670358)

129

Adam Klobukowski napisał/a:

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?

130 Ostatnio edytowany przez BartoszP (2015-09-27 19:47:37)

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.

131

drac030 napisał/a:

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.

132

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.

KMK
? HEX$(6670358)

133

drac030 napisał/a:

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.

134 Ostatnio edytowany przez drac030 (2015-09-27 20:08:50)

Nie lubię Aranyma i nie poprosiłeś wystarczająco ładnie. A w zasadzie wcale.

KMK
? HEX$(6670358)

135

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.

http://demotywatory.pl/4549839/Nowoczesna-technologia

136

BartoszP napisał/a:
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.

.: miejsce na twoją reklamę :.

137

drac030 napisał/a:

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.

138

Da się, tylko nie spełniasz warunków :D

KMK
? HEX$(6670358)

139

skrzyp napisał/a:

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 ?

140

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.

.: miejsce na twoją reklamę :.

141

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;
  }

142

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.

143

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.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

144

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).

145

Cyprian napisał/a:

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.

146

mormon napisał/a:

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.

147 Ostatnio edytowany przez BartoszP (2015-09-28 17:54:18)

swinkamor12 napisał/a:

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.

swinkamor12 napisał/a:

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 ?

148

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ą).

KMK
? HEX$(6670358)

149

swinkamor12 napisał/a:

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.

swinkamor12 napisał/a:

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.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

150

@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.