sparc optflags

[Tomasz Mateja]

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
[builder w moon ~]$ echo __sparcv9__ | gcc -E -m32 -mcpu=ultrasparc -
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
__sparcv9__
[builder w moon ~]$ 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?
[tommat w moon ~]$ rpm -qa | grep busybox
busybox-initrd-1.6.1-1.sparc
[tommat w moon ~]$ 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.