Komentowana treść: AROS64 coraz bliżej
07.10.2007 15:27
[#1]
Re: AROS64 coraz bliżej
Autor chce teraz skupić się na usunięciu widocznych błędów między innymi w dwóch dosyć istotnych komponentach: Zune
No niemożliwe!
Czyżby to oznaczało że z biegiem czasu jednak ten składnik arosa będzie się nadawał do szerszego użytku? ;)
Może drag&drop też z rozpędu zaimplementuje? ;)
No niemożliwe!
Czyżby to oznaczało że z biegiem czasu jednak ten składnik arosa będzie się nadawał do szerszego użytku? ;)
Może drag&drop też z rozpędu zaimplementuje? ;)
07.10.2007 20:59
[#6]
Re: AROS64 coraz bliżej
szkoda ze aros zamiast posuwac sie do przodu ,rozwijac on tylko sie rozlewa na wszystko co mozna nazwac komputerem
08.10.2007 08:49
[#8]
Re: AROS64 coraz bliżej
@DRACOX, post #6
Fajnie jak by sie dynamiczniej ten Aros ROzwijał ale....
AROS64 to juz koniecznosc, tych 32 bitowych x86 juz coraz trudniej pewnie bedzie dostac z czasem zwykłum uzytkownikom i developerom. Wiec pewnie i dobrze ze cos sie z tym dzieje. Jak nie bedzie sie dynamiczniej przez to rozwijał to moze nie bedzie sie rozwijał chociaz "wolniej". Wiec na moje to dobry news.
AROS64 to juz koniecznosc, tych 32 bitowych x86 juz coraz trudniej pewnie bedzie dostac z czasem zwykłum uzytkownikom i developerom. Wiec pewnie i dobrze ze cos sie z tym dzieje. Jak nie bedzie sie dynamiczniej przez to rozwijał to moze nie bedzie sie rozwijał chociaz "wolniej". Wiec na moje to dobry news.
08.10.2007 10:35
[#13]
Re: AROS64 coraz bliżej
@wali7, post #12
Co nie zmienia Faktu ze lepiej to zawczasu zmienic i odrazu juz rozwijac 64 bit niz gnic w 32 i robic potem 2 razy ta sama robote.
NIe zabardzo rozumiem z Kad ta wstecznosc chłopaki ;)
Ot przystosowuja go do 64 bit i tyle.
Dawno juz były prosby zeby to zrobic wiec robia. Wielki mi news ;)
Ostatnia edycja: 08.10.07 10:37:45
NIe zabardzo rozumiem z Kad ta wstecznosc chłopaki ;)
Ot przystosowuja go do 64 bit i tyle.
Dawno juz były prosby zeby to zrobic wiec robia. Wielki mi news ;)
Ostatnia edycja: 08.10.07 10:37:45
08.10.2007 11:32
[#15]
Re: AROS64 coraz bliżej
@dzordan, post #10
Jaki "złom" pecetowy? ;)
64 bitowy hardware jest od jakiegoś czasu dostępny, a mimo to w dalszym ciągu można kupić nowe kompy oparte o zwykłe x86 32 bit.
Poza tym jakie kolejki? ;) Od tego są aukcje internetowe. :P
Chciałbym bardzo żeby amigowcy mieli taką sytuację ze swoim hardware, jaki teraz jest w przypadku x86 32bit...
64 bitowy hardware jest od jakiegoś czasu dostępny, a mimo to w dalszym ciągu można kupić nowe kompy oparte o zwykłe x86 32 bit.
Poza tym jakie kolejki? ;) Od tego są aukcje internetowe. :P
Chciałbym bardzo żeby amigowcy mieli taką sytuację ze swoim hardware, jaki teraz jest w przypadku x86 32bit...
08.10.2007 11:50
[#16]
Re: AROS64 coraz bliżej
@DRACOX, post #14
chm tyle ze x86_64 z kodem 32bit niema problemu
Tak tak. A potem się cieszą ludziska jak głupie, że mają 64-bitowy procesor a na nim szaleje 32-bitowy Windows XP, który nie wykorzystuje niczego, co wniosły ze sobą procesory x86_64 :)
wiec lepiej by zabrali sie za brakujace rzeczy a nie przystosowywanie systemu do mikrofalowek,lodowek czy innych odkurzaczy
Masz ode mnie gwarantowane niemieckie piwo jak tylko wyjdzie pierwszy odkurzacz z x86_64 na pokladzie :)
PS. Zajmuję się niskopoziomowym programowaniem, dłubanie kernela, mieszanie C i C++ z assemblerem nie sprawia mi trudnosci. Czy w związku z zabraniem się "za brakujace rzeczy" mam to rzucić w diabły i dziergać GUI albo rysować tapety?
Ja po prostu robię to co umiem :P
08.10.2007 12:32
[#17]
Re: AROS64 coraz bliżej
@MinisterQ, post #15
wg mnie x86 32bit = złom :)
x86 64 bit tez złom ale nowszy :P
286 i 386 tez mozna zdobyc tylko po co.
wiesz...
rozumiem ze do wiekszosci zastosowan starczy
ludziom duuuzo wolniejszy komputer nawet niz te 32 bitowe pentiumy athlony itd. i na te 64 bity prawie nikt sie jakos nie napala. ze jest mało softu ktory to naprawde wykorzystuje itd i wiecej w tym bełkotu marketingowego. Ale taka jest kolej rzeczy ze odchodzi stare i idzie nowe. .... poprostu.
Ale super ze masz inne zdanie bo mam z kim podyskutowac
....
A te inne rzeczy w arosie do zrobienia tez sa wazne. Na ten Drag&Drop bym si enie obraził :)
Ostatnia edycja: 08.10.07 12:36:26
x86 64 bit tez złom ale nowszy :P
286 i 386 tez mozna zdobyc tylko po co.
wiesz...
rozumiem ze do wiekszosci zastosowan starczy ludziom duuuzo wolniejszy komputer nawet niz te 32 bitowe pentiumy athlony itd. i na te 64 bity prawie nikt sie jakos nie napala. ze jest mało softu ktory to naprawde wykorzystuje itd i wiecej w tym bełkotu marketingowego. Ale taka jest kolej rzeczy ze odchodzi stare i idzie nowe. .... poprostu.
Ale super ze masz inne zdanie bo mam z kim podyskutowac
....
A te inne rzeczy w arosie do zrobienia tez sa wazne. Na ten Drag&Drop bym si enie obraził :)
Ostatnia edycja: 08.10.07 12:36:26
08.10.2007 13:50
[#20]
Re: AROS64 coraz bliżej
@MDW, post #18
Czy przystosowanie programu dla procesorów 64-bitowych polega tylko na tym o czym napisał Krashan?
Mniej wiecej, ale nie do konca :)
Problemem jest to, ze wskaznik nie miesci sie w typie ULONG (ULONG jest nadal 32-bitowy, przy czym ULONG == uint32_t). Do tego, niektore funkcje systemowe sa niejako zlem wcielonym. Na przyklad takie niewinne GetAttr:
ULONG atrybut;
GetAttr(moj_obiekt, attrid, &atrybut);
Cos takiego zadziala na x86_64, a jakze. Problem jest tylo taki ze to co zwraca GetAttr moze byc liczba albo wskaznikiem, zaleznie od pobieranego atrybutu. Dlatego tez w AROSie GetAttr oczekuje w trzecim argumencie typu IPTR*. Oznacza to, ze powyzszy fragment kodu musi byc zamieniony na:
IPTR atrybut;
GetAttr(moj_obiekt, attrid, &atrybut);
W przeciwnym wypadku GetAttr nadpisze jakis niewinny fragment stosu :)
Takich miejsc jest wiecej. Na przyklad, niektore struktury sa przekazywane do funkcji przez wskaznik (na przyklad w DoMethodA()), ale na nieszczescie w systemie (amiga.lib ;)) sa tez odpowiedniki przyjmujace zmienna ilosc argumentow (DoMethod()). Takie funkje sa koszmarne gdyz nie licza sie z tym, ze czesc argumentow moze byc przekazywana do funkcji za pomoca rejestrow. Dodatkowo ignoruja one fakt, ze dane na stosie moga miec troche inne wyrownanie niz to co jest w strukturach. Jeden blad i caly program (albo caly system) lezy... Mozna to rozwiazac za pomoca specjalnie latanego kompilatora (MOS tak ma, AmigaOS4 tak ma, AROS na PPC tak ma). Rozwiazanie zgrabne dopoki sie pozostaje przy jednej jedynej wersji kompilatora :)
Tak czy siak, piszac nowy program trzeba na powaznie stosowac wlasciwe typy danych (np. IPTR/intptr_t dla typow liczbowych mogacych pomiescic wskaznik) i nie zakladac na sztywno rozmiarow obiektow (mialem w AROSie kilka miejsc, gdzie bylo na przyklad AllocMem(ilosc_elementow * 4.... ;)).
Co sie zas tyczy starych programow, sprawdzic nalezy cala mase rzeczy, poprawic niechlujny kod i wyrwac sobie garsc wlosow :) Na szczescie wiele z bykow dosc latwo mozna wylapac :) Podpowiedzia sa wyjatki rzucane przez procesor :)
08.10.2007 14:20
[#24]
Re: AROS64 coraz bliżej
@szuler, post #23
Czyli nic nie trzeba zmieniać jeśli tak jest to zrobione?
Podobnie dajmy na to taka konstrukcja:
ULONG *dupa = AllocVecPooled(pool, memory_size * (sizeof(ULONG*));
zaalokuje wartość pamięci pomnożoną o wielkość 64 bitowych wskaźników, a samo *dupa będzie również 64 bitowym wskaźnikiem?
Czyli de facto wystarczy przekompilować program, pomimo tego że to "brzydko" z punktu widzenia architektury 64bit wygląda?
A co ze strukturami? Jak wiadomo, wspaniały protokół GG używa struktur danych do komunikacji. W przypadku procków 32bit jedynym problemem jest w zasadzie tylko endian, ale w przypadku tak opisanych struktur to będzie rzeźnia:
struct gg_msg_recipients {
char flag; /* == 1 */
int count; /* ilosc odbiorcow */
int *recipients; /* tablica odbiorców */
};
lub:
struct gg_msg_richtext_format {
short position; //* pozycja atrybutu w tekscie *//
unsigned char font; //* atrybuty czcionki *//
char rgb[3]; //* kolor czcionki, nie musi wystapic *//
struct gg_msg_richtext_image image; //* nie musi wyst±pić *//
};
struct gg_notify_reply {
int uin; /* numer */
char status; /* status danej osoby */
int remote_ip; /* adres ip delikwenta */
short remote_port; /* port, na którym słucha klient */
int version; /* wersja klienta */
short unknown1; /* znowu port? */
char *description; /* opis, nie musi wystąpić */
int time; /* czas, nie musi wystąpić */
};
Podobnie dajmy na to taka konstrukcja:
ULONG *dupa = AllocVecPooled(pool, memory_size * (sizeof(ULONG*));
zaalokuje wartość pamięci pomnożoną o wielkość 64 bitowych wskaźników, a samo *dupa będzie również 64 bitowym wskaźnikiem?
Czyli de facto wystarczy przekompilować program, pomimo tego że to "brzydko" z punktu widzenia architektury 64bit wygląda?
A co ze strukturami? Jak wiadomo, wspaniały protokół GG używa struktur danych do komunikacji. W przypadku procków 32bit jedynym problemem jest w zasadzie tylko endian, ale w przypadku tak opisanych struktur to będzie rzeźnia:
struct gg_msg_recipients {
char flag; /* == 1 */
int count; /* ilosc odbiorcow */
int *recipients; /* tablica odbiorców */
};
lub:
struct gg_msg_richtext_format {
short position; //* pozycja atrybutu w tekscie *//
unsigned char font; //* atrybuty czcionki *//
char rgb[3]; //* kolor czcionki, nie musi wystapic *//
struct gg_msg_richtext_image image; //* nie musi wyst±pić *//
};
struct gg_notify_reply {
int uin; /* numer */
char status; /* status danej osoby */
int remote_ip; /* adres ip delikwenta */
short remote_port; /* port, na którym słucha klient */
int version; /* wersja klienta */
short unknown1; /* znowu port? */
char *description; /* opis, nie musi wystąpić */
int time; /* czas, nie musi wystąpić */
};
08.10.2007 14:41
[#25]
Re: AROS64 coraz bliżej
@MinisterQ, post #24
Podobnie dajmy na to taka konstrukcja:
ULONG *dupa = AllocVecPooled(pool, memory_size * (sizeof(ULONG*));
zaalokuje wartość pamięci pomnożoną o wielkość 64 bitowych wskaźników, a samo *dupa będzie również 64 bitowym wskaźnikiem?
tak, ale ja do takiego kodu bym sie nie przyznawal ;). dupa to wskaznik na typ ULONG, a jednoczesnie z kodu wynika, ze alokujesz tablice dla "memory_size"-ilosci wskaznikow na ULONG :P Wiec jak juz, to ULONG **dupa = ....
A co ze strukturami? Jak wiadomo, wspaniały protokół GG używa struktur danych do komunikacji. W przypadku procków 32bit jedynym problemem jest w zasadzie tylko endian, ale w przypadku tak opisanych struktur to będzie rzeźnia...
Az tak zle nie bedzie :) Dziwnym trafem rozmiar int-a sie nie zmienil na 64-bitowym gcc (i w x86_64 SysV ABI) :) Ale dla spokoju ducha moglbys zastosowac albo historyczne amigowe typy (exec/types.h :->), albo przyjemne dla oka typy ze standardu C99 (inttypes.h):
8-bit: BYTE, UBYTE, int8_t, uint8_t
16-bit: WORD, UWORD, int16_t, uint16_t
32-bit: LONG, ULONG, int32_t, uint64_t
64-bit: QUAD, UQUAD, int64_t, uint64_t
typ mieszczacy wskaznik: SIPTR, IPTR, intptr_t, uintptr_t
Te typy wymyslono po to (zarowno amigowe, jak i te na nowo "odkryte" przez komitet standaryzacyjny C), zeby nie stresowac sie rozmiarem typu zaleznym nie tylko od procesora, ale tez od ABI konkretnego systemu (w 64-bitowym windowsie zarowno typ long jak i int sa 32-bitowe)
To na co przede wszystkim musisz uwazac to funkcje typu GetAttr, ktorym musisz przekazac wskaznik do zmiennej w pod ktory te funkcje cos napisza :)
08.10.2007 14:49
[#26]
Re: AROS64 coraz bliżej
@szuler, post #25
Wiec jak juz, to ULONG **dupa = ....
Nie czepiaj sie aż tak poprawności przykładów ;)
To na co przede wszystkim musisz uwazac to funkcje typu GetAttr
Od stu lat mam jedną funkcję do pobierania wartości z obiektów, więc wystarczy tylko w jednym miejscu zmienić. A co do reszty... Staram się trzymać rzeczy dotyczące różnic między systemami w jednym źródle (które wygląda dość odstraszające, bo pełno w nim preprocesora i makr), i zmieniać tylko tam, a nie w całym programie.
Bez tego nie było by możliwe łatwe kompilowanie AmiGG na wszystkie amisystemy, i mam nadzieję że równiez na AROSa 64bit. :)
Nie czepiaj sie aż tak poprawności przykładów ;)
To na co przede wszystkim musisz uwazac to funkcje typu GetAttr
Od stu lat mam jedną funkcję do pobierania wartości z obiektów, więc wystarczy tylko w jednym miejscu zmienić. A co do reszty... Staram się trzymać rzeczy dotyczące różnic między systemami w jednym źródle (które wygląda dość odstraszające, bo pełno w nim preprocesora i makr), i zmieniać tylko tam, a nie w całym programie.
Bez tego nie było by możliwe łatwe kompilowanie AmiGG na wszystkie amisystemy, i mam nadzieję że równiez na AROSa 64bit. :)
08.10.2007 15:06
[#27]
Re: AROS64 coraz bliżej
@MinisterQ, post #26
Nie czepiaj sie aż tak poprawności przykładów
Uperdliwy jestem, wiem :) Sam niechlujnie pisze to sie chociaz tu poczepiam ;P
To na co przede wszystkim musisz uwazac to funkcje typu GetAttr
Od stu lat mam jedną funkcję do pobierania wartości z obiektów, więc wystarczy tylko w jednym miejscu zmienić.
Aros ma do tego makro XGET :)
Bez tego nie było by możliwe łatwe kompilowanie AmiGG na wszystkie amisystemy, i mam nadzieję że równiez na AROSa 64bit.
Na razie musisz poczekac. Kompilator dla DevCpp nie wyjdzie jeszcze przez jakas chwile. Najpierw musze bledy popoprawiac, potem trzeba przemyslec do konca ABI i je raz na zawsze "zamrozic" :)
08.10.2007 19:29
[#30]
Re: AROS64 coraz bliżej
@piteq, post #29
..a nie przystosowywanie systemu do mikrofalowek,lodowek czy innych odkurzaczy....
Od tego jest linux
Niezle, to jaka firma robi takie super AGD ?
#17
wg mnie x86 32bit = złom usmiech
x86 64 bit tez złom ale nowszy
286 i 386 tez mozna zdobyc tylko po co.
Tak kazdy komputer PC wg ciebie to ZLOM w takim wypadku po co go uzywasz? Wyrzuc go na ZLOM .
rozumiem ze do wiekszosci zastosowan starczy
ludziom duuuzo wolniejszy komputer nawet niz te 32 bitowe pentiumy athlony itd. i na te 64 bity prawie nikt sie jakos nie napala. ze jest mało softu ktory to naprawde wykorzystuje itd i wiecej w tym bełkotu marketingowego.
Tak, jak zechce to wykorzystam. Wyobraz sobie ze dzis by zagrac w glupia gre FPP, trzeba miec min 1,5-2,4GHZ proca. Tak naprawde zacznij swoja litanie do programistow ktorzy pisza jak chca.
Aby szybciej i do premiery. :P