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.

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.

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.

Adam Klobukowski napisał/a:

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.

Adam Klobukowski napisał/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.

Adam Klobukowski napisał/a:

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.

Adam Klobukowski napisał/a:

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.

Adam Klobukowski napisał/a:

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.

Adam Klobukowski napisał/a:

Power IBMa, to nie jest dokładnie to samo co procesory PowerPC

Ja wiem....napisałem specjalnie "następcą architektury" a nie "nowszą wersją czy kolejnym modelem". Gdzieś trzeba dokonać skrótu myślowego.