101

swinkamor12 napisał/a:

Dlatego właśnie PowerPC jest takie fajne, bo z jednej strony jest sto razy szybsze od 68k, szybsze od najszybszych emulatorów na PC a z drugiej strony kompatybilne ze starym softem.

swinkamor12 napisał/a:

Kod 68k jest tłumaczony na kod powerpc, i można bez problemu używać np bibliotek 68k w swoim sofcie PowerPC.

swinkamor12 napisał/a:

i już można korzystać w programie pod powerpc,z biblioteki 68k tak jakby była natywna w kodzie powerpc.

Zdecyduj się co do jednej prawdy objawionej.

Musisz dorosnąć i zrozumieć, że mleko wcale nie bierze się z kartonika w lodówce tylko dlatego, że na obrazku jest narysowana łaciata krowa. Nie tacy jak Ty myśleli, że to prawda ale się mylili.

Nie rozróżniasz wykonania kodu od jego emulacji.

AmigaOS4 zupełnie ukrywa tą emulację przed użytkownikiem: http://www.amigaos.net/content/127/exte … pabilities i dlatego WYDAJE CI SIĘ, że to PowerPC wykonuje natywny kod 68K.
Zrozum, albo przynajmniej się postaraj, że nie ma znaczenia jaki procesor wykonuje tą czarną robotę emulacji. To może zrobić nawet 6502. Ilość dodatkowego kodu emulatora pisanego tylko po to aby odwzorować stan emulowanego procesora jest taka, że pojedyncze zmiany kolejności bajtów stanowią co najwyżej znikomy promil całości.
Wbudowany emulator w AmigaOS4 może wykonywać emulacje efektywniej tylko dlatego, że jest wycyzelowany bo inaczej producenci AmigaOS nie mieliby argumentów. Kupując nową Amigę za ciężkie setki lub tysiące Euro oczekiwałbym efektywnego wykonania starych programów. Zwłaszcza, że przecież nowy procesor miał zapewnić efekt mega-łał. Wkurzyłbym się gdyby nagle się okazało, że stare programy działają wolniej niż na oryginalnym sprzęcie.
Masz po prostu marketingowo "wyprany mózg" i powtarzasz hasła handlowe bez poparcia ich żadnymi danymi technicznymi.
Podpierasz się kodem generowanym przez kompilator, który załatwia problem zgodności wszystkiego z wszystkim za ciebie. Zacznij pisać bezpośrednio w assemblerze i zobaczymy wtedy jaki z ciebie twardziel. Gdy pojmiesz jak działa procesor na poziomie poszczególnych operacji, to zobaczysz, że wiele rzeczy, które w C trzeba "kombinować" dla zgodności, na poziomie odpowiedniego kodu asemblera załatwia jedna instrukcja albo nawet nie trzeba nic robić po odpowiednim przemyśleniu struktury programu.

Musisz się pogodzić z faktem, że PowerPC to dla rynku konsumenckiego ślepy zaułek.
I to, że tobie się wydaje, że PowerPC jest lepszym środowiskiem dla emulatora Atari niż Intel większość ma głęboko w poważaniu bo lepiej pisać w środowisku, które może jest wolniejsze ale za to jest napisane uniwersalnie na dziesiątki platform i  ma miliony razy większą bazę potencjalnych użytkowników.

102 Ostatnio edytowany przez drac030 (2015-09-26 11:52:19)

Wydaje mi się po przeczytaniu całej tej dyskusji, że swinkamor12 ma na myśli JIT-a, tylko jest takim wybitnym specjalistą, że nie umie go ani nazwać, ani zbornie opisać jego działania.

KMK
? HEX$(6670358)

103

drac030 napisał/a:

Wydaje mi się po przeczytaniu całej tej dyskusji, że swinkamor12 ma na myśli JIT-a, tylko jest takim wybitnym specjalistą, że nie umie go ani nazwać, ani zbornie opisać jego działania.

Przecież bartek miał tłumaczone że emulowane są tylko kawałki kodu a nie całość.
Że bartek dalej nie rozumie jak działa jit trudno.

Ja to widzę tak. Mam maca mini który kosztował mnie trzy stówy czyli dziesięć razy mniej niż moje nowe i7.
Kod big endian działa na tym macu mini G4 trzy razy szybciej niż emulowany 68k na i7.
A ponieważ ten mini ma procesor big endian to nowym sofcie powerpc używa się starych bibliotek skompilowanych pod 68k równie łatwo jak by były skompilowane pod powerpc.
x86 tego nie zapewnia i nigdy nie będzie, bo większości softu z amigi czy atari na x86 nikt nie przepisze.
Powerpc jest pod tym względem lepsze.
I dlatego fajnie byłoby mieć na tym macu mini również atari czyli freeminta.
Oczywiście dla niektórych tutaj to wielki problem bo to się im nie zgadza z wyznawaną ideologią,
w myśl której powerpc jest drogie, nieprzyszłościowe i ogólnie be.
Ale to jest problem z tą właśnie ideologią a nie z powerpc.

104

No więc zapytam, bo trochę nie rozumiem.
To co stoi na przeszkodzie, byś taki projekt ruszył?
Wolność mamy i demokrację... Broni Ci ktoś?

105

@Swinkamor12, jeśli "pijesz" do mnie to najpierw zapoznaj się o czym piszesz a potem pouczaj innych:

JIT czyli "Just In Time compilation" to technologia stosowana w interpretacji/emulacji kodu, która w skrócie polega to na tym - w skrócie abyś był w stanie ogarnąć te parę zdań w jednym czytaniu - że najczęściej emulowany kod jest tłumaczony (można to nazwać kompilacją) na natywny kod procesora danego komputera i ten wygenerowany kod natywny jest gdzieś zapamiętywany. Następnym razem gdy ponownie będzie trzeba emulować ten sam kod, to emulator wie, że ma już przetłumaczony i zapamiętany ten fragment i uruchamia wcześniej przygotowany kod natywny zamiast bez sensu interpretować ponownie to samo bo to strata czasu. Po pewnym czasie emulator nie emuluje już żadnego kodu a tylko wywołuje wcześniej przekompilowane bloki kodu natywnego. Kod emulowany można by wręcz skasować z systemu i nikt nie zauważyłby, że go nie ma. To jest ta magia, która powoduje, że tobie WYDAJE się, że kod jest wykonywany natywnie.

Koniec. Staraj sie przyswoić ten opis i przestań mnie obrażać.

A teraz trzy sprawy:

Zrozum, że po rekompilacji dowolnego kodu starego procesora albo nawet dowolnego innego wymyślonego i nigdy nie istniejącego na kod natywny zawsze zauważysz wzrost prędkości emulacji. Tak działa np. środowisko Javy. Java jako język i środowisko jest zupełnie odseparowana od konkretnego procesora (choć kiedys stworzono nawet procesor Java implementujacy pierwotne/atomowe rozkazy Javy)

Jeżeli twierdzisz, że PowerPC jest takie super-hiper, to po prostu napisz dla swojego G4 program bootstrap (tak sie kiedyś mówiło) zwany obecnie loaderem, który załaduje minimalny interpreter kodu 68K i w nim uruchom FreeMINT.
Dla takiego EKSPERTA jak Ty to przecież pestka...parę kliknięć w klawiaturę i kod będzie działał. Masz wtedy ATARI na PowerPC.

Emulator zaszyty w AmigaOS, ten o którym zapewnie piszesz bo w sumie niegdy nie określiłeś który,  jest po prostu napisany specjalnie dla tego systemu, wykorzystuje jego możliwości i przez to bardzo wydajny. Jest jednak zupełnie nieprzenośny bo jest bezpośrednio związany z architekturą PowerPC. Gdyby AmigaOS było dostepne dla innych procesorów, to pewno ten emulator byłby napisany dla innego procesora. Inne powszechnie dostępne emulatory są uniwersalne i dlatego mniej wydajne.

Na koniec:

Z tą rewelacyjną i szybką emulacją kodu przez PowerPC widać nie jest tak pięknie bo AmigaOS posiada aż dwa emulatory 68K bo jeden jest powolny ale dokładny a drugi szybki ale trochę niekomaptybilny. Do tego dochodzi emulator samej klasycznej Amigi bo jest potrzebne .... tadaaaaa....wcielenie Win-UAE czyli E-UAE......

Rewelacja...trzy różne środowiska do zapewnienia zgodności ze starym sprzętem....po prostu REWELACJA...SZOK.

106

Pytanie nieco na boku:
Co z emulacją/kompilacją kodu samomodyfikującego się?
O ile rozumiem sensowność zastosowania JIT w przypadku Javy, bo tam nie ma opcji, żeby programowo zmienić kod programu, to jak sobie z tym poradzono w przypadku kodu natywnego, który może przecież sam siebie modyfikować? Co z tą kompilacją w locie wtedy? Nie wywali się toto przypadkiem?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

107

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Brak kodu funkcji fprintf.

Kod funkcji fprintf do ściągnięcia ze strony MOS team.

Ważny jest kod skompilowany do asemblera.

swinkamor12 napisał/a:

W kodzie który przesłałeś nie ma żadnego dostępu pod adres niepodzielny przez 4.

Jest tylko ty nie potrafisz znaleźć.
Mimo że masz w dumpie z kompilatora również linie z c.
Twoja wiedza o powerpc jest za mała.

To wskaż mi proszę, w której linii, w kodzie asemblerowym który pokazałeś, jest dostęp do adresu niepodzielnego przez 4.

swinkamor12 napisał/a:

No, nikt nie zrobił, poza autorami emulatorów takich jak WinUAE, Aranym, Hatarai i wielu innych. To o czym piszesz nie ma nic wspólnego z konwersją little/big endian, to po prostu generowanie stubów dla bibliotek.

Cały czas nie wiesz o czym piszesz. Coś  ci się wydaje ale tylko wydaje.
Spróbuj użyć w kodzie x86 bibliotek z obecnego freeminta 68k, to zrozumiesz o co chodzi.

Ale jak już pisałem większość "ekspertów" którym PowerPc nie pasuje, nigdy tego nie widziała i nie używała.

Skoro nie rozumiem, to mi wytłumacz. Na początku pisałeś że nie pasuje endianess, to Ci BartoszP pokazał że PowerPC w najnowszej Amidze ma takie samo endianess jak Intel. Więc skoro endianess moze być inne niż na 68K, i masz te same 'problemy' z endianess które miałbyś na Intelu, to na czym polega przewaga PowerPC?

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

108

@mono:

Cytat z FAQ autora emulatora 68K w AmigaOS:

The actual version of Petunia is translating only those executables which are not banned by the black list. The default behavior is dynamic translating of any 68k code, which was loaded by DOS, but you can add any executable or library to the black list with the Compatibility preferences program thus avoiding the dynamic translation. Normally you don't have to do this.

109 Ostatnio edytowany przez swinkamor12 (2015-09-27 11:42:48)

mono napisał/a:

Pytanie nieco na boku:
Co z emulacją/kompilacją kodu samomodyfikującego się?

Taki kod powoduje kłopoty z cache i dlatego na amidze czegoś takiego się nie używa.

110

Adam Klobukowski napisał/a:

Ważny jest kod skompilowany do asemblera.

To chyba żart. Jeśli masz z funkcją printf problem ściągnij źródła ze strony MOS team i sam skompiluj do asemblera.

To wskaż mi proszę, w której linii, w kodzie asemblerowym który pokazałeś, jest dostęp do adresu niepodzielnego przez 4.

Załączyłem dump z kompilatora, są tam po kolei linie w c i w assemblerze.

Niestety wbrew twoim wyobrażeniom o powerpc, powerpc jest w stanie pobierać dane 32 bit z adresu niepodzielnego przez 4.

Skoro nie rozumiem, to mi wytłumacz.

Nie ma problemu. Napisz program pod x86 który otworzy okienko na emulowanym freemincie 68k,
po czym będzie coś tam rysował, okienko da się przesuwać będzie reagował na klawisze, mysz.
Po praktycznym zapoznaniu się z problemem wymiany danych z pewnością zmienisz zdanie o powerpc.


Szczerze mówiąc pomijam brednie bartka. Oczywiście najnowsze PowerPC są big endian tak jak wszystkie poprzednie, niektóre tylko da się przełączyć w tryb little endian.
Więc nie tak jak intel który jest tylko  little endian.

111

Ja to widzę tak. Mam maca mini który kosztował mnie trzy stówy czyli dziesięć razy mniej niż moje nowe i7.
Kod big endian działa na tym macu mini G4 trzy razy szybciej niż emulowany 68k na i7.
A ponieważ ten mini ma procesor big endian to nowym sofcie powerpc używa się starych bibliotek skompilowanych pod 68k równie łatwo jak by były skompilowane pod powerpc.

Oczywiście niektórym to się nie zgadza z wyznawaną ideologią w myśl której powerpc jest be.
No cóż fakty są takie jakie są. Jest to fajne rozwiązanie które się sprawdziło na amidze i działa.
Jeśli niektórzy jak bartek np mają problem z pogodzeniem się z faktem że rzeczywistość jest inna niż ich wyobrażenia to ich problem.
Powerpc jest fajne bo szybkie, tanie i kompatybilne.
I właśnie dlatego powtarzam chciałbym mieć na swoim macu mini również atari czyli freeminta.

112 Ostatnio edytowany przez BartoszP (2015-09-27 12:21:30)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Nie porównujesz szybkość kodu emulowanego z natywnym na różnych platformach.

Zgadza się w obu przypadkach kod big endian.

To są brednie....to tak jakbyś porównywał osiągnięcia Hitlera i Rubensa - nie Rubensa Barrichello tylko Petera Rubensa - argumentując to tym, że obaj przecież byli malarzami...tylko, że jeden pokojowym a drugi artystą....co to za różnica przecież..malarz to malarz.

swinkamor12 napisał/a:

Oczywiście najnowsze PowerPC są big endian tak jak wszystkie poprzednie, niektóre tylko da się przełączyć w tryb little endian.
Więc nie tak jak intel który jest tylko  little endian.

Gdybyś tylko zapoznał się choć trochę z listą rozkazów procesora PowerPC, to są tam rozkazy, które ładują dane little-endian do rejestru we właściwej postaci mimo, że zapisane są w big-endian. Jeden rozkaz assemblera bez żadnych opóźnień.
Jeśli dla Ciebie pisanie dla PowerPC kończy sie na kompilatorze GCC, to jest to tak jakbyś twierdził, że jesteś doświadczonym mechanikiem samochodowym tylko dlatego, że potrafisz wymienić wycieraczki.

PS.
Odrobina kultury wymaga aby imiona i zaimki pisać wielką literą na początku....ale nie wiem czy można tego od Ciebie oczekiwać czy też ma to być element "przysrywania", którym maskujesz swoją niewiedzę.

113

Widzę że bartek nadal ma problem z pogodzeniem się z faktem że rzeczywistość jest inna niż jego wyobrażenia o powerpc.
No cóż przykro mi.
Niestety powerpc jest fajne bo szybkie, tanie ,kompatybilne i co ważne działa.
I właśnie dlatego powtarzam chciałbym mieć na swoim macu mini również atari czyli freeminta.

114

Brakuje puenty......kiedy zaprezentujesz freemint na fajnym, tanim, szybkim i co najważniejsze kompatybilnym MacMini ?

PS.
Jak widać po poprzednim poście kultura jest Ci obca mentalnie.....nie tacy jak Ty próbowali mnie obrazić ale im się nie udawało.

115

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Ważny jest kod skompilowany do asemblera.

To chyba żart. Jeśli masz z funkcją printf problem ściągnij źródła ze strony MOS team i sam skompiluj do asemblera.

Nie mam kompilatora dla ppc, ani całej reszty potrzebnych do tego narzędzi. Ty masz, juuż orezentowałeś kawałek kodu, w czym problem z resztą?

swinkamor12 napisał/a:

Skoro nie rozumiem, to mi wytłumacz.

Nie ma problemu. Napisz program pod x86 który otworzy okienko na emulowanym freemincie 68k,
po czym będzie coś tam rysował, okienko da się przesuwać będzie reagował na klawisze, mysz.
Po praktycznym zapoznaniu się z problemem wymiany danych z pewnością zmienisz zdanie o powerpc.

Znam ten 'problem' wymiany danych z praktyki, przerabiałem go wielokrotnie, jak większość programistów. Napisałem sporo kodu który musiał zmagać się z konwersją little/big endian i nie rozumiem twojego problemu. Więc wytłumacz mi na konkretnym przykładzie - na czym polega problem? Pokaż ten strasznie skomplikowany, trudny, powolny kod.

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

116 Ostatnio edytowany przez swinkamor12 (2015-09-27 16:50:06)

Adam Klobukowski napisał/a:

Nie mam kompilatora dla ppc, ani całej reszty potrzebnych do tego narzędzi. Ty masz, juuż orezentowałeś kawałek kodu, w czym problem z resztą?

Pomysły typu dekompilacja standardowej funkcji z stdio to żart.
Nie wiem czego chcesz tam szukać. To po prostu działa.
Powerpc bez problemu sięga do danych 32 bit z adresu niepodzielnego przez 4.
Jeśli się to nie zgadza z twoimi wyobrażeniami o powerpc, cóż twój problem.
A skąd pomysł, że powerpc ma jakieś z tym problemy?

swinkamor12 napisał/a:

Znam ten 'problem' wymiany danych z praktyki, przerabiałem go wielokrotnie, jak większość programistów.
Napisałem sporo kodu który musiał zmagać się z konwersją little/big endian i nie rozumiem twojego problemu. Więc wytłumacz mi na konkretnym przykładzie - na czym polega problem? Pokaż ten strasznie skomplikowany, trudny, powolny kod.

Proszę bardzo:
Napisz program w C pod x86 który otworzy okienko na emulowanym freemincie 68k,
po czym będzie coś tam rysował, okienko da się przesuwać będzie reagował na klawisze, mysz,
plus oczywiście będzie korzystał z jakiś kontrolek.

O tu powiedzmy na początek:

http://dev-docs.atariforge.org/files/CO … V2_AES.pdf

strona 84 program scroll.c

A potem powiedzmy coś z drzewkami

strona  125 object.c

A potem może jeszcze strona 164 dialog1.c

117

To już jest zrobione. Obrazki Ci wystarczą ? http://hatari.tuxfamily.org/scrshots.html

118

Przypominam tylko Calamusa pod Windows… :)

.: miejsce na twoją reklamę :.

119

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Nie mam kompilatora dla ppc, ani całej reszty potrzebnych do tego narzędzi. Ty masz, juuż orezentowałeś kawałek kodu, w czym problem z resztą?

Pomysły typu dekompilacja standardowej funkcji z stdio to żart.
Nie wiem czego chcesz tam szukać. To po prostu działa.
Powerpc bez problemu sięga do danych 32 bit z adresu niepodzielnego przez 4.
Jeśli się to nie zgadza z twoimi wyobrażeniami o powerpc, cóż twój problem.
A skąd pomysł, że powerpc ma jakieś z tym problemy?

http://www.freescale.com/files/product/ … FPE32B.pdf
4.1.5: "(...)An attempt to access memory with an effective address alignment that is invalid for the instruction
causes the alignment interrupt handler to be invoked(...)"

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Znam ten 'problem' wymiany danych z praktyki, przerabiałem go wielokrotnie, jak większość programistów.
Napisałem sporo kodu który musiał zmagać się z konwersją little/big endian i nie rozumiem twojego problemu. Więc wytłumacz mi na konkretnym przykładzie - na czym polega problem? Pokaż ten strasznie skomplikowany, trudny, powolny kod.

Proszę bardzo:
Napisz program w C pod x86 który otworzy okienko na emulowanym freemincie 68k,
po czym będzie coś tam rysował, okienko da się przesuwać będzie reagował na klawisze, mysz,
plus oczywiście będzie korzystał z jakiś kontrolek.

O tu powiedzmy na początek:

http://dev-docs.atariforge.org/files/CO … V2_AES.pdf

strona 84 program scroll.c

A potem powiedzmy coś z drzewkami

strona  125 object.c

Nie nic tu nie tłumaczysz. Pokaż mi swój kod, albo jakikolwiek kod, na którym możesz zademonstrować problem. Nie 'napisz se kod', bo ja już trochę kodu w życiu napisałem. Wskaż mi konkretny kawałek kodu gdzie ten 'problem' występuje i wytłumacz dlaczego tak jest.

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

120

Adam Klobukowski napisał/a:

http://www.freescale.com/files/product/ … FPE32B.pdf
4.1.5: "(...)An attempt to access memory with an effective address alignment that is invalid for the instruction
causes the alignment interrupt handler to be invoked(...)"

A dalej jest:

6.5.6.1 Integer Alignment Interrupts
Operations that are not naturally aligned may suffer performance degradation, depending on the processor
design, the type of operation, the boundaries crossed, and the mode that the processor is in during
execution. More specifically, these operations may either cause an alignment interrupt or they may cause
the processor to break the memory access into multiple, smaller accesses with respect to the cache and the
memory subsystem.

Czyli jak widzisz, nie zawsze powoduje to niedziałanie programu, na niektórych procesorach jest tak jak na 68k, dostęp do 32 bit danych pod adresem niepodzielnym przez 4 jest możliwy.

Nie 'napisz se kod', bo ja już trochę kodu w życiu napisałem. Wskaż mi konkretny kawałek kodu gdzie ten 'problem' występuje i wytłumacz dlaczego tak jest.

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.

121 Ostatnio edytowany przez drac030 (2015-09-27 18:03:02)

swinkamor12 napisał/a:

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.

Ten program to trzystronicowy listing w C wydrukowany maczkiem. Niestety, obawiam się, że musisz znaleźć coś, co w sposób prosty i jednoznaczny zilustruje problem, o którym piszesz. Bez "wywołań systemu", po prostu przykład obróbki danych, która się nie uda (da błędne wyniki), jeśli zastosujemy do niej konwersję BE<>LE. Siadasz, piszesz 10-15 linijek w C, i tu wklejasz. Z komentarzem. I to my ocenimy, czy ten przykład jest przekonujący, więc lepiej, żeby był.

I nie, nikt dla Ciebie nie będzie portował całego systemu operacyjnego razem z GEM-em, bibliotekami, kompilatorem C i Bóg wie czym jeszcze na x86 tylko po to, żeby sprawdzić, że się mylisz i istotnie żadnego problemu nie ma (BTW. GEM jest tak w ogóle przeportowany na Atari z PC, indiańskość w parameter arrays, w plikach RSC i w plikach IMG jakoś w tym nie przeszkodziła).

Tak prościej: to Ty twierdzisz, że w suficie jest dziura, a nikt poza Tobą jej nie widzi - a zatem to na Tobie spoczywa tzw. onus probandi, że ona faktycznie tam istnieje. Nikt inny nie jest póki co tym "problemem" zainteresowany, bo nikt nie widzi tu żadnego problemu.

KMK
? HEX$(6670358)

122

drac030 napisał/a:

Ten program to trzystronicowy listing w C wydrukowany maczkiem. Niestety, obawiam się, że musisz znaleźć coś, co w sposób prosty i jednoznaczny zilustruje problem, o którym piszesz.
Bez "wywołań systemu".

Nie zrozumiałeś. Ten program jest idealny.
O to właśnie chodzi że muszą być wywołania systemu, wymiana różnych skomplikowanych danych między różnymi procesorami.
To czekam aż się Adam Klobukowski wykaże i skompiluje to pod x86.

I nie, nikt dla Ciebie nie będzie portował całego systemu operacyjnego razem z GEM-em, bibliotekami, kompilatorem C i Bóg wie czym jeszcze na x86

Ależ właśnie o to chodzi żeby skorzystać z kodu 68k bez przerabiania.

123

swinkamor12 napisał/a:

Ten program jest idealny.

Skoro jest taki idealny, to go sobie sam skompiluj, uruchom i poinformuj nas, w którym miejscu napotkałeś problem.

KMK
? HEX$(6670358)

124

drac030 napisał/a:

Skoro jest taki idealny, to go sobie sam skompiluj, uruchom i poinformuj nas, w którym miejscu napotkałeś problem.

Nie zrozumiałeś. Ja twierdzę że się nie da bez dużego nakładu pracy.
Natomiast Adam Klobukowski że wymiana danych między x86 a x68k to nie problem.
Skoro nie problem to czekam aż weźmie i pokaże że to nie problem.

125

swinkamor12 napisał/a:
drac030 napisał/a:

Skoro jest taki idealny, to go sobie sam skompiluj, uruchom i poinformuj nas, w którym miejscu napotkałeś problem.

Nie zrozumiałeś. Ja twierdzę że się nie da bez dużego nakładu pracy.
Natomiast Adam Klobukowski że wymiana danych między x86 a x68k to nie problem.
Skoro nie problem to czekam aż weźmie i pokaże że to nie problem.

To przedstaw cokolwiek co demonstruje ten problem, bo my twierdzimy że go nie ma.

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