AMD64 - kdo doda HW?

[Jan Kasprzak]

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;
pokud bych chtel ukladat nejaka takova data na disk, musim to vedet nebo
musim pouzivat typy explicitni delky jako uint32_t). Podle meho nazoru
ve svete PC bude prechod 32->64 bitu _vyrazne_ jednodussi (aspon v Linuxu)
protoze vetsina aplikaci je davno psana bez zavislosti na velikosti typu
int a dalsich (vsimnete si, ze nepisu 64-bitova - IMHO 64-bitova aplikace
je stejne zlo jako 32-bitova nebo 16-bitova).

: 	No ona Alpha byla taky jen 32-bit po urcitou dobu...

Coze? Neplacejte nesmysly. Alpha je od zacatku 64-bitovy procesor (tim myslim
ze ma registry velke 64 bitu, umi delat 64-bitove aritmeticke operace,
ma 64-bitovy virtualni adresni prostor, atd).

: coby virtualni stroje fine, ale realne na cem se behal (nikoliv experimentoval) bezne Linux?
: 
	SGI Altix? Ten koupite s Linuxem primo od vyrobce.

: > 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.
: 
: 	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"?).


-Jan Kasprzak

PS.: Zalamujte zpravy na <80 znaku (jak je napsano i v Meta-FAQ),
	neda se to po Vas cist.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
|  I actually have a lot of admiration and respect for the PATA knowledge  |
| embedded in drivers/ide. But I would never call it pretty:) -Jeff Garzik |