AMD64 - kdo doda HW?

[Jan Derfinak]

On Mon, 24 Nov 2003, Pavel Janoušek wrote:

> 	Prominte, ale bylo celkem zvykem rozlisovat 'bitovost' aplikace
> 	podle toho, jaka velikost (v bitech) byla u typu INT - myslim, ze s

Myslim, si ze je to Vas zvyk a nie vseobecne pravidlo.

> 	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

To nie je vymysel intelu. Ak sa nemylim tak linux na Alphe to ma tiez tak.
Skor to povazujem za Vasu chybnu domienku, vychadzajucu zo zvyku, ktory Ste
prezentoval v uvode. Vysvetlite mi na co je dobre, ze int a long budu mat tu
istu velkost aj na 64-bit. arch. tak ako je to 32-bit. arch.?

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

To je sice pravda, ale nezda sa Vam nedostatocne aplikovat poznatky zo Z80 na
dnesne procesory a tvrdit, ze linux je v sucasnosti iba 32-bitovy?

> 	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

V tom pripade si nainstalujte 64 bitovu distribuciu a hladajte tam
"zle" napisane programy. Ked ich tam najdete tak to budu "realne" programy.
Napriek tomu, ze si to mozte vyskusat a realne argumetovat, tak stale sa
pohybujete v teoretickej urovni Vasej predstavy.

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

Napiste mi, co chcete vyuzit a potom Vam napisem ako to napisat.
Alebo, co by bolo lepsie nastudujte si teoriu a myslim, ze na vela
Vasich otazok si budete vediet odpovedat sam.

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

V jednoduchosti:
Aplikacia pouziva pamatovy priestor, ktory si ziada od OS. OS, pokial je
schopny jej ho pridelit, tak jej ho prideli, inac ziadost vrati s chybovym
kodom. Na zaklade toho aplikacia zisti, ci moze dalsi pamatovy priestor pouzit
alebo nie. V tom nie je ziadna 64-bitova magia, tak pracuje kazda normalna
aplikacia a tych je v linuxe dostatok.
 
> > > 	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

V takom pripade, je dolezite podla akeho standartu je navrhnuty kompilator,
aky standard pouziva autor zdrojoveho kodu a ako ho dodrzuju.
Pokial sa nezhodnu v standartoch, tak to je smola, ale musi sa riesit na
inej urovni. Jednoducho motor z nakladaku do skodovky asi nepojde. :)
Pokial maju rovnaky standard, tak niekto z nich urobil chybu, ale je
standard nepresne definovany. A to zase nesuvisi s temou tejto diskusie.

				jano

--