[builder-ac-amd64@pld-linux.org: ERRORS: scorched3d.spec]

[Jakub Bogusz]

On Tue, Apr 13, 2004 at 10:16:34PM +0200, Paweł Sikora wrote:
> roznica IMO jest taka, ze jedziemy na protezie LP64 by 32-bitowe
> nieprzenosne (sztywno zakladajace, ze int to 4 bajty) zrodla
> sie nie posypaly po kompilacji na x86_64. jest tylko kwestia
> czasu przejscie na natywne (dla procesorow) ILP64.

W sumie nie wiem jak ta "natywność" dokładnie wygląda w przypadku
amd64, jako (prawie) pochodnej x86 przez dalsze rozciąganie rejestrów
(al, ax -> eax -> rax). Kod 32-bitowy też się na tym wykonuje
"natywnie". I nie wiem, czy parametry zrzucane na stos są
(>=) 64-bitowe... (częste SEGV przy braku prototypu sugerowałoby,
że nie).

W przypadku alphy wygląda to już bardziej jednolicie (dla danych),
fragmenty 64-bitowych rejestrów są _jakoś_ dostępne (nie wnikałem
jak - co ciekawe w trybie natychmiastowym można przypisywać tylko po
16 bitów, bo rozkazy mają stałą długość 4 bajtów - ale nie w stylu
x86/x86_64) - ale tu też się zdecydowali na 32-bitowego inta,
może po prostu za tru64 - tak jak używane na Linuksie ABI (dla
procesora - tzn. umowne przeznaczenie (i alternatywne nazwy) rejestrów,
przekazywanie parametrów (teraz byśmy to nazwali "regparm=6" ;)),
implementacja ramek stosu itp.) jest zgodne z tym tradycyjnym.

> nasz przykladowy fragment kodu powinien nosic miano
> "jak wydymac kompatybilnosc LP64" :-D
> warto zauwazyc, ze przy natywnym sprzetowo ILP64 nic by sie nie stalo.

Ale nie można zakładać, że int zmieści wskaźnik.
(nie zawsze prawdziwe nawet pod DOS-em)

<offtopic>a Win64 ponoć miało mieć (nie wiem czy tak zostało)
LLP64</offtopic>


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/