Proc by se mel kernel nebo glibc nebo cokoliv dalsiho specialne portovat na 64bit architekturu? Neni to snad pouze zalezitost compileru, aby vyuzil vsechno novy registry, SSE2, atd.?
Jak se to vezme - kernel je rozhodne potreba portovat, protoze se jedna o novou architekturu, ktera umi novy veci. Uz treba to, ze AMD64 ma vic registru, ktere je potreba ukladat do vsemoznych struktur. Navic jeho casti jsou napsane v assembleru a ten se pochopitelne musi prepsat.
Co se tyka glibc, tak tam je to podobne - prepisou se assemblerovske casti (tedy povetsinou rucne optimalizovane rutiny), doplni se headery, atd.
GDB musi porozumnet novemu formatu souboru (elf64 misto elf32), novemu formatu debugovacich informaci, ...
No a GCC, to je kapitola sama pro sebe ;-)
Samozrejme u user-level programu by v idealnim pripade zadne specialni portovani nemelo byt potreba.
Hadej proc 32bitove OS maji vetsinou omezenou velikost souboru na 2GB ? protoze programatori si rikali ze offset jako 32bit cislo staci. Takze napriklad 64bit offset je v tomto pripade rozhodne lepsi a prikladu by bylo vice. Rozhodne si myslim ze zpetna kompatibilita je cesta do pekel.
OK, nepredpokladam ale, ze by nekdo pouzival typy int32 apod. Kazdej normalni clovek si prece definuje fileoff_t a o tom pak rekne, kolik ma bitu, takze veskery "portovani" spociva ve zmene par znaku nekde v hlavicce, ne?
Hm, ty mas vsechna data jen v pameti a na disk je pises v ASCII, ze ti muze byt jedno, jak je "int" (nebo "long") velky?
Jinak ale je pri prechodu z 32bit na 64bit par pekne schovanych kulisaren (napriklad htonl - kolik ze bitu ma ten jeho "long"?) a jen trochu neporadneji napsane C si namlati hubu na tom, ze "assuming external returning int" nemuze vratit pointer, nebot ten je 64-bit.
Samotneho me prekvapilo, jak casto se v mem kodu objevuje implicitni predpoklad, ze long a int jsou zamenitelne typy. Osklivy nesvar z DOSu i z Windowsu, tezko se ho zbavuje. Treba %d a %ld v printfu mam tendenci plest porad...
