AMD64 - kdo doda HW?

Pavel Janoušek janousek na fonet.cz
Úterý Listopad 25 10:21:16 CET 2003


> -----Original Message-----
> From: Jan Derfinak [mailto:ja na mail.upjs.sk] 
> > 	ve vetsine pripadu DATOVE! (vyjimky jako I8088 a I80386 
> SX neberu v
> > 	potaz...) Takze o jakem zlozvyku mluvite, ze neplati?
> O tom, ze sa bitovost berie podla velkosti typu INT. 

	Ano a od toho se odviji schopnost pocitat v ALU (tedy zpravidla registr A, AX apod.) a od toho se odviji s jakym cislem jsem schopen efektivne pocitat - je prima mit na 8-bitove platforme knihovnu pro praci s opravdu velkymi cisly - ostatne, existuje i v Linuxu a je velmi pouzitelna, bohuzel vykon takoveho systemu je spise do oblasti badani, ne pouzitelnosti... (protoze je to implementovano pres string, nic lepsiho nikdo nevymyslel....)

	Takze AX = 16 bitu proto sizeof(int) = 2, EAX = 32 bitu, proto sizeof(int) = 4.

> Mne sa to zda. Napriek tomu, ze priznavate ze nesledujete 
> sucasny vyvoj, tak

	Nesleduji = nevim o nuancich, ktere byly dodelany na Alpha, Opteron, IA64, s390 apod. v poslednim pul roce... ne ze bych byl uplne mimo...

> 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.

> Okrem toho 64 bitove platforma uz existuje mozno aj 10 rokov, 
> takze Linux ma
> svoje prve kroky v tejto oblasti uz davno za sebou. Okrem 

	No ona Alpha byla taky jen 32-bit po urcitou dobu... coby virtualni stroje fine, ale realne na cem se behal (nikoliv experimentoval) bezne Linux?

> toho Linux je len
> jadro OS. GNU programy, ktore tvoria distribuciu funguju aj 
> na Solarise,
> Tru64, AIX, IRIX... a ich 64-bitovost dufam nehodlate 
> spochybnovat. Takze
> pokial Ste schopny dokazat Vase tvrdenie o neexistencii 64 
> bitoveho Linux,
> urobte tak. Pokial nie, ziadam Vas aby Ste prestali mystifikovat.

	Mozna to je zakladni nase vzajemne nepochopeni. Ve Vasem pojeti Linux = kernel, vse ostatni je GNU apod. (tedy nikoli operacni system Linux) V mem pojeti Linux = operacni system Linux - stejne jako OS MS Windows neni jen kernel32.dll... - rozdilnost definic jsem si jiz vsiml, proto jsem se snazil vzdy nejprve definovat...

> unsigned long velka_pamat;
> ...
> if ((m = malloc (velka_pamat)) == NULL)
>   printf ("nemozem alokovat pamat");
> else
>   nacitavam_velke_data(m);
> 
> Pokial taky program prelozite ako 32-bitovy bude moct 
> alokovat iba pamat
> pristupnu 32 bitovym aplikaciam. Pokial ho prelozite ako 64 
> bitovy bude moct
> alokovat pamat adresovatelnu v 64 bitovom rezime. V kazdom 
> pripade vyuzijete
> maximum pamate, ktore Vam poskytne architektura. Rozdiel je 
> vo velkosti dat,
> ktore je schopny spracovat. Ale o to ide, 64-bitova architektura ma
> predsa rozsirit moznosti, inac by nebola potrebna.

	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);

	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...

> Co Ste tym chceli povedat? Pokial ten kernel s gcc prelozite, tak je
> vsetko v poriadku. Pokial niektore gcc kernel neprelozi a vyvojari
> identifikovali chybu v gcc a opravili ju, tak chyba bola v gcc. Ale
> suvislost s existenciou 64 bitoveho linuxu mi unika.

	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)...

> Nikto sa tu nebavi o POKUD. Ale dobre pokial mi ukazete 
> skodovku z motorom
> napriklad z liazky tak Vam uverim. Ale pokial nie, tak je to len Vasa,
> nepodlozena hypoteza.

	Jenze Vy jsme mel to POKUD take - bud Kernel a GCC nebo jazyk C... - bez predpokladu neni vysledku:-)

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


Další informace o konferenci Linux