AMD64 - kdo doda HW?
Karel Zak
zakkr na zf.jcu.cz
Úterý Listopad 25 12:59:44 CET 2003
On Tue, Nov 25, 2003 at 11:31:37AM +0100, Jan Kasprzak wrote:
> Pavel Janoušek wrote:
> : Vy povazujete prechod 32 -> 64 za hladky, ja nikoliv, nejen z
> : duvodu historickych zkusenosti.
>
> Nezapomente, ze v dobe 16-bitovych systemu byla vetsina veci psana
> v assembleru. Dnes kdy jednak mam programy ktere uz davno na 64-bitovych
> systemech bezi a jednak jsou psany v C nebo v necem vyssim, staci uplne
> to, ze se v hlavickovych souborech zmeni definice typu off_t, ssize_t
> a podobnych a nemusim zadnou 64-bitovost resit. Nechapu proc by me jako
> programatora melo zajimat, jak velky mam int nebo long (tedy v pameti;
Ono hodne jde to jakou kazen mel programator. Neni pochyb, ze na urovni
knihoven to je/bude snadne, ale nebyl bych si jist jak moc lidi si
dava pozor na to kde a jak pouziva int na misto nejake presnejsi
definice. Ostatne peknym prikladem neceho podobneho, muze byt podpora
velkych (rozumej vetsich nez sizeof(int)) souboru v ruznych programcich
a utilitach (napriklad v "mc") a ne moc nedavna nutnost oprav prave z
duvodu neutuchajici lasky mnoha lidi k prostemu "int" :-)
Jinak souhlas, u vetsich a dnes jiz portovanych aplikaci bych to
nevidel jako problem. Daleko vice bych se bal programu, kde je sotva
nejake ./configure.
> : > unsigned long velka_pamat;
> : > ...
> : > if ((m = malloc (velka_pamat)) == NULL)
> : > printf ("nemozem alokovat pamat");
> : > else
> : > nacitavam_velke_data(m);
> : >
> : To je hezkla ukazka HODNE PRASACKEHO kodu, ktery jste nejprve
> : odsoudil - je pravda, ze long mate 64-bit - to tak bude vzdy? Pokud
> : se divam do reference ke GLIBC, tak vidim u malloc tuto deklaraci
> : (ANSI C bude vyhovovat vzdy, Vas kod tuto vysadu mit nemusi):
> : void *malloc(size_t size);
>
> Long je v ANSI C definovan jako nejvetsi numericky typ, se kterym umi
> CPU efektivne pracovat. Prasacke to neni, ale lepsi by bylo pouzit size_t.
Je to uplne jedno pokud mate jistotu jake hodnoty do te promenne
ukladate. Jistotu nemate pokud volate nejake externi veci jako treba
stat().
> : Tak a ted mi reknete bez testovani a analyzy jak z kristalove
> : koule poznate velikost toho size_t? Bavili jsme se snad o
> : portabilnich programech, dle toho by mely vypadat i programovaci
> : konstrukce... Zajimal by me CISTY zpusob (a bez if - to je prace
> : progamatora, vy tvrdite, ze je to prace pro kompilator) - ja ho
> : nejsem schopen vymyslet, proto se po nem pidim, kdyz rikate jak je
> : to snadne a jak to kompilator zaridi za nas...
> sizeof(size_t)
>
> : Ne chtel jsem rici, ze jednotny zaklad v Linux kernelu (C & ASM)
> : nestaci, a ze kompilator si nemuze domyslet... proto tam nelze
> : pouzit Intel C, ktery produkuje na modernich Intel CPU kvalitnejsi
> : kod nez GCC (zejmena pokud do toho pocitame SIMD instrukce jakekoli
> : urovne)...
>
> Intel C nelze pouzit proto, ze zdrojaky kernelu obsahuji spoustu
> GCC-specifickych konstrukci (jak udelate v Intel C pametovou barieru?
> Jak reknete ze tato funkce ma jit do jine sekce nez ".text"?).
Bylo by vubec zajimav prohnat vetsinu GNU software jinym kompilatorem
nez GCC, mozna by se naslo par gcc-ismu i v jinych vecech.
> PS.: Zalamujte zpravy na <80 znaku (jak je napsano i v Meta-FAQ),
> neda se to po Vas cist.
Nemluve o tom, ze uz mu to bylo receno asi 100x :-)
Karel
--
Karel Zak <zakkr na zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
Další informace o konferenci Linux