08.07.2020 10:11
[#1]
68k JIT.
Witajcie. Nie wiem czy to dobre miejsce na ten temat, ale czy słyszeliście o bibliotece dla AmigaOS, która umożliwi poczciwej Motorolce emulować siebie samą z włączonym JITem? Czyli takie UAE dla AmigaOS dostało by sporego przyspieszenia.
link
PS: Jeśli coś pomieszałem, to proszę aby mnie poprawiono.
link
PS: Jeśli coś pomieszałem, to proszę aby mnie poprawiono.
08.07.2020 10:50
[#3]
Re: 68k JIT.
@recedent, post #2
Pytanie tylko - po co poczciwa Motorolka ma emulować samą siebie?
Bo dobrze napisany JIT jest w stanie wypasc wydajnosciowo tak samo jak natywny kod, a czasami (ale to raczej nie w tym przypadku) przegonic kod natywny o kilka-kilkanascie procent.
Poza tym takie rozwiazanie pozwoliloby chocby na uzycie nie do konca kompatybilnych procesorow ColdFire, chociaz w tym przypadku juz troche za pozno na tego rodzaju projekt ;)
I na koniec, najwazniejszy argument - bo autor projektu tak chce, ma zachciewajke na napisanie czegos takiego. Wiec niech pisze na zdrowie!
08.07.2020 10:53
[#5]
Re: 68k JIT.
@mschulz, post #3
dobrze napisany JIT jest w stanie wypasc wydajnosciowo tak samo jak natywny kod, a czasami (ale to raczej nie w tym przypadku) przegonic kod natywny o kilka-kilkanascie procent.
To durne ludzie podkręcają swoje chińskie 060 do 100+ MHz a wystarczyłoby napisać "dobrze napisany JIT"?
@Don Adan:
A nie można zrobić takiego myku jak w emulatorach Macintosha, które emulacją CPU zasadniczo w ogóle się nie zajmują, bo po co?
Ostatnia aktualizacja: 08.07.2020 10:54:54 przez recedent
08.07.2020 11:02
[#6]
Re: 68k JIT.
@recedent, post #5
To durne ludzie podkręcają swoje chińskie 060 do 100+ MHz a wystarczyłoby napisać "dobrze napisany JIT"?
I po co ta ironia?
The HP project Dynamo was an experimental JIT compiler where the 'bytecode' format and the machine code format were the same; the system turned PA-6000 machine code into PA-8000 machine code. Counterintuitively, this resulted in speed ups, in some cases of 30% since doing this permitted optimizations at the machine code level, for example, inlining code for better cache usage and optimizations of calls to dynamic libraries and many other run-time optimizations which conventional compilers are not able to attempt.
Szczegolow poszukaj w sieci.
08.07.2020 11:26
[#9]
Re: 68k JIT.
@recedent, post #5
A nie można zrobić takiego myku jak w emulatorach Macintosha, które emulacją CPU zasadniczo w ogóle się nie zajmują, bo po co?
Slyszalem ze jest na Amige taki emulator jakiejs platformy (automat do gier) ktory pracuje
poprawnie i najszybciej tylko na 030. Posiadanie innego procesora powoduje krasze i inne
nieprzewidziane problemy.
Nie, nie jest zle napisany. Poprostu w tym emulatorze procesor nie jest emulowany a w tym
automacie siedzi wlasnie 030.
Ostatnia aktualizacja: 08.07.2020 11:30:45 przez Phibrizzo
08.07.2020 15:07
[#13]
Re: 68k JIT.
@recedent, post #5
Z tego co wiem to chyba wszystkie programy Maca sa system friendly, czyli nie uzywaja zadnych rejestrow bezposrednio tylko chyba przez ROM, wiec wystarczy tylko ROM spatchowac i moze system Maca. Problem z innymi systemami 68000 jest z emulacja rejestrow (zapis/odczyt) oraz z adresowaniem (wszystkie tryby z adresowaniem .L, .W). Na przyklad instrukcja move.l A0,$DFF0A0, oznacza zapis adresu sampla na Amidze do rejestru Pauli, ale ta sama instrukcja na jakimkolwiek innym systemie 68000 bedzie co innego robila. Do tego dochodza takie sprawy, ze niektore odwolania sa np. do obszarow pamieci/rejestrow, gdzie Amiga ma swoje rejestry lub ROM, lub akurat nie ma tam zadnej fizycznej pamieci zamontowanej.
08.07.2020 15:11
[#14]
Re: 68k JIT.
@Ponki1986, post #1
Ale emuluje siebie samą - w sense dany cpu emuluje dokładnie taki sam model? Czy raczej na nowszym emulujesz starszy? Czy chcesz osiągnąć taki efekt że AmigaOS na emulatorze działałby szybciej niż ten AmigaOS (taki sam jak pod emulatorem) z którego odpalasz ten emulator? To chyba byłby jakiś paradoks, coś jak próba podniesienia się za włosy.
W tym przypadku JIT to nie byłaby kompilacja, bo kod emulowany jest taki sam jak wykonywany, tylko coś jak optymalizacja na poziomie asemblera.
Potencjalny zysk miałbyś tylko wtedy gdyby loader kodu potrafił go mocno zoptymalizować przed uruchomieniem (potrzeba na to czasu i sporo pamięci), albo nawet tak jak w javie - analizować kod podczas wykonywania i optymalizować w locie (raczej dla dłużej działających programów powtarzających wiele takich samych operacji, jak serwery - no i zabiera czas prawdziwego cpu temu emulowanemu). Poza tym - czy obsługa samego emulatora nie zeżre całego potencjalnego zysku z jita?
W tym przypadku JIT to nie byłaby kompilacja, bo kod emulowany jest taki sam jak wykonywany, tylko coś jak optymalizacja na poziomie asemblera.
Potencjalny zysk miałbyś tylko wtedy gdyby loader kodu potrafił go mocno zoptymalizować przed uruchomieniem (potrzeba na to czasu i sporo pamięci), albo nawet tak jak w javie - analizować kod podczas wykonywania i optymalizować w locie (raczej dla dłużej działających programów powtarzających wiele takich samych operacji, jak serwery - no i zabiera czas prawdziwego cpu temu emulowanemu). Poza tym - czy obsługa samego emulatora nie zeżre całego potencjalnego zysku z jita?
08.07.2020 15:13
[#15]
Re: 68k JIT.
@] SKOLMAN_MWS ˇ agrEssOr [, post #7
Ale to raczej nie jest problem. Jedynie emulacja dzwieku moze byc bardziej procesorozerna niz emulacja samego procesora, bo zwykle te uklady audio maja wiecej niz 4 kanaly, i wtedy to jeszcze miksowac trezba kanaly, a to jest wolne. Oczywiscie mowie tu o targecie z karta graficzna jak Vampire czy Warp. Takie NeoGeo calkiem dobrze dziala na Vampirze, i w zasadzie mogloby dzialac na kazdej Amidze z szybka karta graficzna i 68060. Moze oprocz dzwieku.