AMD64 - kdo doda HW?

[Pavel Janoušek]

> -----Original Message-----
> 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 - myslim, ze s tim short ci char ma pramalo spolecneho a bylo naprosto normalni povazovat za 16-bit aplikaci tu, ktera mela int ve 2 bytech, za 32-bit aplikaci tu, ktera mela int ve 4 bytech - drzim se teto konvence i nyni... To, ze Intel prichazi s tim, ze INT bude zase "jen" 32-bitu na 64-bit CPU je docela hlina..:-) - sam s tim zacal uz od 4-bitovych CPU (I4004, kde aritmeticky registr mel 4 bity)... Stejne jako Z80 neoznacujeme za 16-bit procesor, ackoli mel spoustu 16-bit registru (namatkou IX, IY, HL, BC, DE), ale pouze 8-bitovy, protoze registr A ("aritmeticky") mel skutecne jen 8-bitu.

> parametrov sa pouziju registry: RDI, RSI, RDX, RCX, R8, R9. 
> Vsetky su 64
> bitove. Uz toto vylepsenie oproti i386, zlepsuje vykon, lebo 
> nie je nutne
> predavat parametry cez zasobnik a teda odpada praca s pamatou.

	Tohle je pro mne prilis nove a neorientuji se v tomto... (priznavam a pujdu studovat...:->) - ja jsem skoncil u predavani parametru pres zasobnik nebo pomoci registru (pokud jich bylo dost).

> Vsetko co Ste popisali, sa ale nieriesi v aplikacii, ale libc 
> hlavickovych
> suboroch. Pokial pozijete spravne typy (teda nie int, ale 
> off_t), tak sa Vam
> program spravne prelozi aj na 32 aj na 64 architekture, kde 
> bude mat off_t
> 64 bitov. Pokial program nepouziva off_t, tak nie je 32 
> bitovy, ale zle
> napisany.

	Uprimne, mluvil jsem o realnych programech, tam se tyto konvence dobre mixuji, programu, ktere nejsou napsany "zle", jak pisete, je jak safranu a stejne to neresi to, ze aplikace si musi zjistit maximalni adresovatelnou velikost, neco jako off_t_max apod. a dle toho pracovat... - prece nechcete nechat na procesoru preteceni na adresu 0x00000000... Fakt by me zajimalo, jak byste takovouto aplikaci psal, abyste nemusel zjistovat na jake -bitove architekture pracujete, ale optimalne ji vyuzival...

> Ved aj pracuje, off_t je automaticky 64 bitovy, volacia 
> konvencia je 64
> bitova, pamatovy priestor nie je obmedzeny na 3GB...

	Ale to aplikace nevi a bud si to aktivne zjistuje (malo aplikaci) nebo pracuje s "rozumnou" velikosti, ktera se ale neodviji od 32-bitu vs. 64-bitu...

> > 	No pri soucasnem navrhu to jinak zrejme nejde, ono jde 
> spise o to,
> > 	ze ty vnitrnosti musi mit take dohodnute API (linux kernel prece
> > 	nekomunikuje pomoci front zprav) a co vyhovuje x86 CISC nemusi
> > 	vyhovovat z hlediska optimalniho behu a vykonu RISCu ci 
> jinym apod.
> 
> Nie je toto uloha prekladaca pre danu architekturu?

	I dnes je vhodne prekladaci pomoci. Mozna pro Vas neni tajemstvim, ze ani dnes bez hacku v GCC by nesel prelozit ani Linux kernel. Oba snad vime, ze velmi optimalni a kvalitni C kompilator produkuje Intel - zkuste to jadro prelozit... nemate sanci. A kdo jiny zna vhodnost servirovani instrukci jednotlivym jednotkam lepe nez vyrobce dotycneho systemu?

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