Jakub Bogusz wrote: > Swoją drogą opcja -mv8plus (przynajmniej dla gcc 3.3.5, do nowszego > nie mam teraz dostępu) nie ma wpływu na wynikową binarkę: > - przekazane przy kompilacji dla <=v8 nie robi nic, bo v8 nie ma > 64-bitowych rejestrów > - dla >=v9 asembler i tak dostaje -Av9a (lub -Av9b) i tworzy ELF > z ABI SPARC V8+ > Czyli co najwyżej -mno-v8plus wyłączy używanie 64-bitowych rejestrów, > ale binarka i tak będzie typu SPARC32PLUS. > Pamietam ze ktorys pakiet mial jakies assemblerowe wstawki i normalnie nie przechodzilo a z -mv8plus dalo rade (gcc 4.2) wiec chyba ma szerszy zakres polecen. > > Co do nazewnictwa, to jest zamieszanie: > ABI SPARC - wiadomo, 32-bitowe, %g5 zarezerwowany dla systemu > ABI SPARC V8+ - jw rozszerzone o 64-bitowe rejestry global i out, > %g5 dostępny jako scratch; wymaga procesora _V9_ (UltraSPARC) > ABI SPARC V9 - w pełni 64-bitowe > > Pod Solarisem sparcv9 oznacza właśnie ABI SPARC V9 (odpowiednik > sparc64 z Linuksa). > Pod Linuksem sparcv9 to nadal 32-bitowe ABI z -mcpu=v9 (-mcpu=v9 > dodaje definicję makra __sparc_v9__ - co jest błędnie rozumiane > jako sparc64 przez niektóre programy; być może jest to prawda > pod Solarisem - nie wiem, nie mam w tej chwili jak sprawdzić). > eeeeeeee [EMAIL PROTECTED] ~]$ echo __sparcv9__ | gcc -E -m32 -mcpu=ultrasparc - # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" __sparcv9__ [EMAIL PROTECTED] ~]$ echo __sparc__ | gcc -E -m32 -mcpu=ultrasparc - # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" 1
> > IMO skoro port th/i386 z kodem wymagającym i486 nazywamy i486, a nie i386, > to portu wymagającego UltraSPARC-a też nie powinniśmy nazywać sparc, > tylko od typu minimalnego wymaganego procesora. > config.gcc to akurat nie problem - łatwo poprawić. > Trochę większy z pomieszaniem nazw (niektórym sparcv9 sugeruje, że to > sparc64) - ale to zamieszanie i tak już jest... > > Poza tym jeśli sparc znaczyłoby sparcv9, to jak odróżnić tę > podarchitekturę w specu, żeby np. przekazać jakieś inne opcje dla > configure? "%ifarch sparcv9" by nie działało. > Nawet jeżeli domyślne byłoby v9, to nie zgadzam się na blokowanie > na poziomie speców możliwości budowania pakietów na v8. > > > Kolejna rzecz: jeżeli decydować się na v9 jako minimum w linii dystrybucji > - wszystkie rzeczy kernelowe na sparc i sparcv9 nie mają racji bytu[1]. Tylko > sparc64. > > [1] dotyczy też takich drobiazgów jak obsługa modułów jądra w 32-bitowej > wersji busyboksa (32-bitowa nie umie nic zrobić z 64-bitowymi) > > he? [EMAIL PROTECTED] ~]$ rpm -qa | grep busybox busybox-initrd-1.6.1-1.sparc [EMAIL PROTECTED] ~]$ rpm -q kernel kernel-2.6.22.19-1.sparc64 ale spoko luz wlasnie mi sie mieli gcc spatchowane --target=sparcv9 wiec podejmuje wyzwanie. Tylko mielenie paczek bez automatyki dla 3 arch to nie wiem ile mi snu pozostanie ;P. Ktos poprowadzi za raczke jak to postawic? Dam znac jak v9 bedzie mialo base do budowania. (w sumie nie jest tak strasznie - zawsze mozna posluzyc sie pakietami sparc) Pozdrawiam -- T. _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl