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.

Takie że porównujesz samochód z drzewem.

Nie w teorii, ale w praktyce. Widziałem kod emulatora, pisałem kod emulatora i uruchamiałem wiele emulatorów.

Adam Klobukowski napisał/a:

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.

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

swinkamor12 napisał/a:

Dlatego powerpc jest takie fajne.

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

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

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.

Adam Klobukowski napisał/a:

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

Zgadza się w obu przypadkach kod big endian.

Adam Klobukowski napisał/a:

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.

nadal porównujesz na jednym kod emulowany, a na drugim nartyny.

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

Poczytaj trochę jak to działa, to przestaniesz rozpowiadać nieprawdę.

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:

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.