Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Posty przez swinkamor12
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.
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.
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.
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?
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.
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.
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.
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.
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?
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
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.
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.
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.
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.
Zastanawiam się nad kompatybilnością firebee z oryginalnym oprogramowaniem z atari st. Sprzętowo wykonuje kod czy przez wbudowany emulator.
Część sprzęt (90%) a część wbudowany emulator (10%).
Proporcje mogą się różnić zależnie od używanego softu.
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.
Brak kodu funkcji fprintf.
Kod funkcji fprintf do ściągnięcia ze strony MOS team.
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.
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.
Pokaż wygenerowany kod w asemblerze, łącznie z funkcją printf, to będziemy mogli o tym dyskutować.
A proszę bardzo kod w asemblerze, plus dump z kompilatora z dodatkowymi informacjami.
Tobie do jakiegokolwiek kombinowania brakuje podstawowej wiedzy.
Wydaje ci się że obejdziesz problem konwersji danych be <-> le kombinowaniem z kodem emulatora.
Niestety tak ci się tylko wydaje. Byli już tacy co kombinowali tak jak ty i im też nie wyszło.
A na powerpc (i na innych be pewnie też tylko na razie nikt nie zrobił) sprawa jest bardzo prosta:
generuje się jeden nowy plik jedną linia w shellu i już można korzystać w programie pod powerpc,
z biblioteki 68k tak jakby była natywna w kodzie powerpc.
nadal porównujesz na jednym kod emulowany, a na drugim nartyny.
Zgadza się w obu przypadkach kod big endian.
To słabo sprawdziłeś. Na PowerPC, próba odczytania 32 bitowej wartości z adresu który nie jest podzielny przez 4 spowoduje błąd, na 680x0 możesz sobie czytac 32 bitowe wartości spod adresów podzielnych przez 2, a na 68020+ spod dowolnego adresu (tu musi być jednak wsparcie płyty głównej, i Amiga jest chyba w tym temacie ułomna)
Nie wiem skąd masz te informacje. Na moim G4 działa.
MOSRoot:test_da> type test.cpp
#include <stdio.h>
int main()
{
int a[2]={0x01020304,0x05060708};
char *p0=(char*)a;
p0=p0+2;
int *b=(int*)p0;
fprintf(stdout,"%x\n",a);
fprintf(stdout,"%x\n",p0);
fprintf(stdout,"%x\n",b);
int c=b[0];
fprintf(stdout,"%x\n",c);
return 0;
}
MOSRoot:test_da> gcc test.cpp -o test
MOSRoot:test_da> test
2d45e178
2d45e17a
2d45e17a
3040506
MOSRoot:Instalki/test_da>
Nie ma znaczenia jakie dane. Emulator przy odczycie konwertuje little-big endian wszystkie dane, bo tak się ich spodziewa aplikacja.
I nie ma znaczenia czy to będzie grafika, muzyka, tekst, czy cokolwiek innego.
Nie, tobie się wydaje że będzie działać zawsze. Niestety tylko tak ci się wydaje.
Jak będziesz ładować jako long i zmieniać kolejność bajtów przy ładowaniu,
gdy nie jest to potrzebne to stary kod nie będzie działać.
Przy np danych graficznych dostaniesz sieczkę na ekranie.
Poczytaj trochę jak to działa, to przestaniesz rozpowiadać nieprawdę.
Myśmy już takich widzieli co to kombinowali tak jak ty.
Niestety okazało się że czasami działa ale nie zawsze.
Nie porównujesz szybkość kodu emulowanego z natywnym na różnych platformach.
Zgadza się w obu przypadkach kod big endian.
No własnie nie zawsze, bo choćby na PowerPC masz problem z data aligment - odczyt danych spod adresu który pod 68K zadziała
bezproblemowo, na PowerPC wywróci aplikację.
Aż sprawdziłem te rewelacje. Masz złe informacje. Na PowerPC działa bez problemu.
Big/little endian nie powoduje żadnej komplikacji - poza ta którą ty tu wymyślasz. Little endian, big endian - nie ma żadnej różnicy pod względem łatwości emulacji.
Jak jesteś takim praktykiem, to pokaż proszę praktyczny przykład gdzie to sprawia problemy.
Dane tekstowe, dane graficzne.
Nie wiesz czy ładując 4 bajty spod danego adresu, powinieneś je zamienić czy nie.
Amigowe c2p na przykład.
A bez przeróbek na procesorze big endian będzie działać zawsze.
Takie że porównujesz samochód z drzewem.
Porównuje szybkość wykonywania kodu big endian z szybkością wykonywania kodem big endian czyli samochód z samochodem.
Nie w teorii, ale w praktyce. Widziałem kod emulatora, pisałem kod emulatora i uruchamiałem wiele emulatorów.
W teorii oczywiście. Niestety praktyka tu się rozmija z teorią.
Ludzie nie piszą idealnego kodu i mają różne dziwne pomysły.
Np przepisywanie stringów po 4 bajty żeby było szybciej.
Ładowanie danych graficznych do rejestrów procesora po 4 bajty.
itp itd.
A jak nie trzeba przerabiać danych to działa zawsze.
Dlatego powerpc jest takie fajne.
Raz jeszcze....teraz twoja kolej EKSPERCIE...ja nie muszę nic udowadniać, że to działa.
To gdzie ten sprzęt z biedronki?
Czyli porównujesz emulowany na i7 do natywnego. Nie wiesz o czym mówisz.
Ale kogo to obchodzi czy emulowany czy nie?
Co to ma za znaczenie?
Liczy się tylko że natywny kod G4 big endian jest szybszy niż emulowany kod big endian na i7.
Widziałeś na oczy kod źródłowy jakiegokolwiek emulatora? Ja widziałem kilku. Konwersja little-big endian jest trywialną operacją i w aboslutnie znikomy sposób komplikuje sam emulator. Nie jest to żaden problem
Czyli widziałeś kod źródłowy jakiegoś emulatora i ci się wydaje Konwersja little-big endian jest trywialną operacją.
W teorii oczywiście. Jak rejestry są pod stałym adresem to pewnie tak.
Ale w praktyce to tylko ci się wydaje. Jak masz bardziej skomplikowane struktury danych to już nie jest to takie proste.
Na procesorach big endian można te problemy po prostu pominąć.
Nie ma potrzeby by robić dodatkową zupełnie niepotrzebną pracę przy pisaniu kodu który będzie dane przerabiał, lub dostawał się do nich w inny sposób.
Dlatego powtórzę jeszcze raz, powerpc jest lepsze dla amigi i atari niż x86.
Ja nie muszę nic pokazywać. Ja nie twierdziłem, że mam taki program i że cokolwiek uruchamiałem. Ja tylko twierdzę, że procesory ARM nawet w tanich tabletach mają takie możliwości z okazji swojej architektury.
Na razie to tylko coś wymyślasz. Pokaż że to działa.
Mylisz się. Pierwszy MacOS ze wsparciem dla PowerPC to był 9.2, czyli classic, bez ochrony pamięci. Przejście na architekturę unixową było później, wraz z MacOS X
Ale pytanie było o przejście z PowerPC na x86.
To było w 2005, parę lat po przejściu na unixa.
Oczywiście jeśli chodzi o wersję MacOS ze wsparciem dla PowerPC to pierwszy był Mac OS 7.1.2 w 1994 roku.
Ot choćby to
http://www.biedronka.pl/pl/product,id,2 … 3g-starter
A uruchomiłeś na tym soft w trybie big endian, czy tak sobie tylko teoretyzujesz?
atari.area forum » Posty przez swinkamor12
Wygenerowano w 0.017 sekund, wykonano 54 zapytań