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 » Software, Gry - 16/32bit » Freemint dla power pc
Strony Poprzednia 1 2 3 4 5 6 7 8 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
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.
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.
Raz jeszcze....teraz twoja kolej EKSPERCIE...ja nie muszę nic udowadniać, że to działa.
To Ty twierdzisz, że tylko PowerPC jest tak dobry, że bezpośrednio wykonuje kod 68K tylko dlatego, że jest big-endian.
Takie bzdury piszesz, że nawet do własnych słów się nie przyznajesz.
Tu masz przykład działania Linux'a na ARM big-endian: https://www.youtube.com/watch?v=-CnA633HhtE
Dalej dyskutujesz ?
Twierdzisz, że masz tyle doświadczenia i wiedzy, że nie dorastamy Ci do pięt.
Pokaż przykład jak to się robi na Amidze. Wklej jakiś zrzut ekranu, YouTube, pokaż benchmarki. Cokolwiek co uwiarygodni twoje słowa.
[EDIT]
A tu poczytaj sobie co twórcy MIPS Linux piszą o problemach-emulacji:
http://www.linux-mips.org/wiki/Endianess
Jestem przekonany, ze maja więcej doświadczenia niż Ty. Nieporównywalnie.
Cytuje dla Cibie bo pewno nie przeczytasz: The overhead from endianess swapping in software rarely shows up in benchmarks at all.
@swinkamorskadwanaście: pokaż mi tani sprzęt na PowerPC na którym będziemy tego używać.
Z gwarancją producenta oczywiście.
Panowie się chyba dobrze bawią, jak widzę… :)
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.
Takie że porównujesz samochód z drzewem.
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.
Nie w teorii, ale w praktyce. Widziałem kod emulatora, pisałem kod emulatora i uruchamiałem wiele emulatorów. Nie wiem o jakich 'rejestrach' tutaj mówisz.
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.
W praktyce, jest to zupełnie pomijalny problem. Nie ma żadnej niepotrzebnej pracy, bo to jest kilka linijek kodu.
Raz jeszcze....teraz twoja kolej EKSPERCIE...ja nie muszę nic udowadniać, że to działa.
To gdzie ten sprzęt z biedronki?
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.
To gdzie ten sprzęt z biedronki?
A jeśli nie jest z biedronki to co to zmienia ?To już nie jest procesor ARM ? Chłopcze...bądź poważny ....
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 porównujesz szybkość kodu emulowanego z natywnym na różnych platformach.
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ą.
Nie, wszystko to robiłem w praktyce.
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.
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.
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.
Dziwnym trafem procesory w architekturze PowerPC firmy Freescale - bo w sumie to nie ma procesora PowerPC bo to nazwa architektury a nie konkretnego procesora - są głównymi procesorami w tych nowych "Amigach" X5000 http://www.amigaos.net/hardware/133/amigaone-x5000
Gdy spojrzeć tu w dokumenty producenta http://cache.freescale.com/files/archiv … 823LEM.pdf , to okazuje się, że te procesory te maja dwa natywne tryby little-endian i jeden big-endian.
Co za supryza dla EKSPERTÓW od emulacji...cała teoria idzie w maliny [ oparte o ARM oczywiscie :) ] bo nagle okazuje się, że big-endian jest BE.
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.
.
Adam Klobukowski napisał/a:Nie porównujesz szybkość kodu emulowanego z natywnym na różnych platformach.
Zgadza się w obu przypadkach kod big endian.
Zmieniasz front, bo Ci BartoszP wtyknął? To nadal nie ma znaczenia, to są zupełnie inne procesory i nadal porównujesz na jednym kod emulowany, a na drugim nartyny.
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.
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)
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.
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.
Co więcej, pomijając emulatory, praktycznie każdy transfer danych przez internet jest robiony w big-endian (większość protokołów sieciowych przesyła bajty w kolejności big endian). I każda aplikacja na każdej platformie sobie z tym doskonale radzi i nie musi wiedzieć nic na temat danych które transferuje. Poczytaj trochę jak to działa, to przestaniesz rozpowiadać nieprawdę.
A bez przeróbek na procesorze big endian będzie działać zawsze.
Czyli dowolny procesor ARM uruchomiony w wersji big-endian też jest tak cool i trendy jak 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 wiem skąd masz te informacje. Na moim G4 działa.
Panie swinkamor12 może zaczniesz dyskutować z firmą IBM ? http://www.ibm.com/developerworks/library/pa-dalign/
Po prostu system operacyjny + środowisko wykonawcze programu wynikowego obsługuje wyjątki generowane podczas dostępu do niewyrównanych danych.
Szczegóły opisane są w pkt. 6.5.6 tego dokumentu http://www.freescale.com/files/product/ … FPE32B.pdf
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>
W tym kodzie nie ma nic, co by wymuszało wygenerowanie przez kompilator odczytu słowa 32 bitowego spod adresu niepodzielnego przez 4.
Pokaż wygenerowany kod w asemblerze, łącznie z funkcją printf, to będziemy mogli o tym dyskutować.
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.
W zaemulowanym środowisku nie ma to znaczenia. Emulowana aplikacja widzi wszystko w takim endianess w jakim się spodziewa i nie ma znaczenia jakie to dane, bo emulator nie ma szklanej kuli i nie potrafi powiedzieć czy $BAADCODE to początek sampla, element grafiki czy może kod.
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.
Tobie do jakiegokolwiek kombinowania brakuje podstawowej wiedzy.
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: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.
Brak kodu funkcji fprintf. W kodzie który przesłałeś nie ma żadnego dostępu pod adres niepodzielny przez 4.
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.
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.
Aż sobie z ciekawości w oczekiwaniu na popcorn sprawdziłem.
http://infocenter.arm.com/help/index.js … jgdid.html
ARM Compiler toolchain Assembler Reference Version 5.01
Home > ARM and Thumb Instructions > General data processing instructions > REV, REV16, REVSH, and RBIT
REV, REV16, REVSH, and RBIT
Reverse bytes or bits within words or halfwords.
Show/hideSyntax
op{cond} Rd, Rn
where:
op
is any one of the following:
REV
Reverse byte order in a word.
REV16
Reverse byte order in each halfword independently.
REVSH
Reverse byte order in the bottom halfword, and sign extend to 32 bits.
RBIT
Reverse the bit order in a 32-bit word.
cond
is an optional condition code.
Rd
is the destination register.
Rn
is the register holding the operand.
Show/hideUsage
You can use these instructions to change endianness:
REV
converts 32-bit big-endian data into little-endian data or 32-bit little-endian data into big-endian data.
REV16
converts 16-bit big-endian data into little-endian data or 16-bit little-endian data into big-endian data.
REVSH
converts either:
16-bit signed big-endian data into 32-bit signed little-endian data
16-bit signed little-endian data into 32-bit signed big-endian data.
Show/hideRegister restrictions
You cannot use PC for any register.
You can use SP in ARM instructions but these are deprecated in ARMv6T2 and above. You cannot use SP in Thumb instructions.
Show/hideCondition flags
These instructions do not change the flags.
Show/hide16-bit instructions
The following forms of these instructions are available in Thumb code, and are 16-bit instructions:
REV Rd, Rm
Rd and Rm must both be Lo registers.
REV16 Rd, Rm
Rd and Rm must both be Lo registers.
REVSH Rd, Rm
Rd and Rm must both be Lo registers.
Show/hideArchitectures
Other than RBIT, these ARM instructions are available in ARMv6 and above.
The RBIT ARM instruction is available in ARMv6T2 and above.
These 32-bit Thumb instructions are available in ARMv6T2 and above.
These 16-bit Thumb instructions are available in ARMv6 and above.
Show/hideExamples
REV r3, r7
REV16 r0, r0
REVSH r0, r5 ; Reverse Signed Halfword
REVHS r3, r7 ; Reverse with Higher or Same condition
RBIT r7, r8
Niestety za malo mam wiedzy o architekturze PPC aby sie tutaj wypowiadac, a tego posta napisalem tylko po to zeby przypomniec pewna madrosc etapu ktora zawarlem w stopce. Cytat z eksperckiej wiedzy. Szanujcie ;)
Właśnie sprawdziłem czy 6502 ma jednostkę zmiennoprzecinkową, i wyszło mi że ma :D
Oto dowód:
Altirra 8K BASIC 1.38
Ready
10 A=1.230490
20 B=2.342352
30 ?A*B
RUN
2.88224071Ready
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.
Strony Poprzednia 1 2 3 4 5 6 7 8 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Software, Gry - 16/32bit » Freemint dla power pc
Wygenerowano w 0.027 sekund, wykonano 61 zapytań