AMD64 - kdo doda HW?

[Michal Ludvig]

Pavel Janousek wrote:
 > From: Pavel Kankovsky [mailto:peak na argo.troja.mff.cuni.cz]
 > > pulka obsazeneho mista budou same nuly) v pripade, ze
 > > hardware umi stejne
 > > dobre pracovat i s 32 bitovymi hodnotami.
 >
 > IA64 ci Opteron oplyva temito vlastnostmi? Ja si naopak vybavuji,
 > ze nam vzdy tloukli do hlavi, ze padding na urovni HW prinasi zbytecne
 > kontrukcni problemy a pokud je to mozno, necha se to na kompilatoru...

AMD64 (Opteron) umi stejne rychle pracovat se 32b cisly jako se 64b
cisly - nic se nepaddinguje - proste se pouzije jen spodni polovina
registru a obsah horni pulky povetsinou zustane zachovan (pokud nejde
o nejake zero- nebo sign-extensions). Je to podobne jako prace se 16b 
pulkami registru na i386 (vsak je take registr RAX (64b) stale pristupny 
i pod jmenem EAX (32b) a dokonce i jako AX (16b) nebo AH/AL (8b)).

Pavel Janousek wrote:
 > From: Jan Derfinak [mailto:ja na mail.upjs.sk]
 > > Myslite to snad tak, ze pokial budem vo svojej aplikacii na i368
 > > pouzivat short alebo char, tak bude moja aplikacia 16/8 bitova?
 > > Int je 32 bitovy a 32
 >
 > Prominte, ale bylo celkem zvykem rozlisovat 'bitovost' aplikace podle
 > toho, jaka velikost (v bitech) byla u typu INT

Ale ale to jsou mi novinky! V nasich krajich je zvykem urcovat
bitovost aplikace podle velikost adresy. Na i386 je pointer 32b, na
AMD64 64b a na starych 8086 to bylo 16b (kdyz pominu magii se
segmenty).

 > > Neupieram Vam Vase historicke znalosti. Ale neodbocujte od temy,
 > > pretoze nemozete aplikovat problemy MS Windows spred 10 rokov do
 > > sucasneho Linuxu.
 >
 > Vy povazujete prechod 32 -> 64 za hladky, ja nikoliv, nejen z
 > duvodu historickych zkusenosti.

No vidite a on skutecne pomerne hladky je. Jiste - pri portovani
Linuxu na AMD64 se hodne zmenily predevsim zalezitosti primo se tykajici
hardwaru - kernel se musel naucit pracovat s vetsimi adresami, 
             strankovat v novem rezimu, podporovat HyperTransport a 
tisic dalsich
veci. K prelozeni a odladeni (nejen) jeho je samozrejme potreba
toolchain - gcc, binutils; pro userspace navic i gdb a glibc. To je
plus minus vsechno, kde bylo potreba vyvinout nejake vyraznejsi usili
pri portovani na AMD64.

Ale co pak? Slusne napsane user space programy bezely prakticky ihned
- dokonce vcetne "molochu" typu XFree86 nebo KDE, celou distribuci v
64 bitech melo SuSE k dispozici uz v dobe SuSE Linuxu 8.1, cili na
podzim roku 2002, tedy zhruba pul roku pred oficialnim uvedenim
Opteronu na trh. Nikoliv 10 let po jejich uvedeni, jak jste nekde ve
svych prispevcich predpovidal vy. Oracle i DB2 jiz maji plne funkcni
databaze portovane na AMD64 (shodou okolnosti vim, ze v pripade Oraclu
je platformove/bitove zavisleho kodu jen naprosto nepatrne mnozstvi).

A netvrdte, ze bez masivniho prepsani soucasne aplikace nedokazi ze 64
bitu tezit! Uz jen to, ze pro novou architekturu AMD64 je nove napsano
ABI (Application Binary Interface) nezatizene nepotrebnou zpetnou
kompatibilitou naproste vetsine aplikaci slozitejsich nez "Hello
World" pomuze. A programy typu GIMP, ktere hodne pocitaji a hodne
pracuji s pameti uz po pouhem prekompilovani na AMD64 temer skacou
radosti :-)

Porad netusim, kde vidite ten problem s nedostatkem aplikaci... Vzdyt
i Mozilla mi tu bezi: "Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.5) Gecko/20030925" :-))

Takze kde je pri prechodu na 64 bitu hacek?
(tedy pokud odhledneme od vasich utkvelych predstav vychazejicich z
prehistorickych zkusenosti :-)

Michal Ludvig
-- 
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/~mic