AMD64 - kdo doda HW?

[Jan Derfinak]

On Fri, 21 Nov 2003, Pavel Janoušek wrote:

> 	Prvni na cem bych se rad zastavil je to, co je vlastne 64-bitova
> 	aplikace. Vetsina aplikaci, ktere jsem mel tu cest videt (zejmena z
> 	oblasti GNU - a to ted nemyslim stare "core" veci, ale spise vyvoj
> 	rekneme v poslednich 5-ti letech) je napsana tak, ze:
> 
> a) pouziva int (CPU/architecture depend)

Int je 32 bitovy na 32 bitovej platforme aj na 64 bitovej platforme aspon v
oblasti intel/amd.

> b) vubec nezjistuje, zda-li bezi na "vetsi" (64-bit) platforme
> 

Nemyslim, ze by to mala zistovat. Na zistenie maximalnych hodnot existuju v
systeme rozne konstanty a tie su rozne na 64 bitovych a 32 bitovych
platformach. Spravne napisanu aplikaciu je mozne prelozit ako na 32 tak aj
na 64 bitovej platforme a bude schopna vyuzit maximum prostriedkov, ktore
jej system poskytne. Musim povedat, ze Vas model programovania ma dost desi.

> 	Na jednu stranu to usnadnuje vyvoj na stranu druhou to zaroven
> 	znamena, ze vse, co aplikace dela je "implementovano" do 32 bitu,

Pokial potrebujete vacsiu hodnotu ako 32 bitov na 64 bitovej architekture
tak pouzijete long. Po prelozeni na 64 bitovej architekture bude tato
hodnota 64 bitova.
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
bitovy zostava aj na 64 bitovej architekture. Pokial sa autor rozhodne
pouzit ho vo svojej aplikacii, znamena to, ze mu jeho rozsah vyhovuje a
nepotrebuje vacsiu hodnotu.

> 	protoze programator pouzil pouze 32-bit funkce/volani...

Co je 32-bitova funkcia/volanie na 64-bit. architekture? Volacia konvencia na
Amd64 je definovana tak, ze pouziva 64-bitove registry. Na predavanie
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.


> 
> 	Popisu konkretni situaci, na ktere to IMHO musi byt silne videt. Je
> 	znamo kolik se vejde do int v 32-bitovem rezimu. Je to nekde v radu
> 	GB dat. Proto mame v Linuxu klasickou funkci fseek, fseeko, lseek,
> 	llseek. fseek nam nepomuze, protoze ma offset jako long (=> vzdy
> 	32-bit = je to pravda? - vychazim z tohoto: "On many architectures

Nie je to pravda. Long je na 64 bitovych pocitacoch 64 bitovy.

> 	both off_t and long are 32-bit types, but compilation with #define
> 	_FILE_OFFSET_BITS 64 will turn off_t into a 64-bit type" - o long
> 	ani zminka, ze by se "zvetsoval"). fseeko ma offset jiz jako off_t,
> 	jenze ten je 64-bitovy pouze v pripade #define _FILE_OFFSET_BITS 64
> 	- kolik aplikaci (source) to ma detekovano a nastavovano? lseek sice
> 	pouziva offset jako off_t, ale situace je podobna jako v fseeko -
> 	kolik aplikaci ma nastaveno patricne makro. llseek je kapitola sama
> 	pro sebe, protoze sice ma "lo" a "hi" cast, ale kompilatoru na
> 	64-bit platforme nezbyde nic jineho nez do "ulong" udelat padding =>
> 	CPU musi v datove casti precist dvojnasobne mnozstvi dat, nez bylo
> 	treba.

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.

> 	Takze zaver - za 64-bitovou aplikaci nepovazuji takovou, ktera byla
> 	navrzena a odladena pro 32-bitovy rezim a byly pouze source vzaty a
> 	prekompilovany 64-bit kompilatorem. Aplikace musi proste aktivne s
> 	64-bit platformou pracovat.

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

> 	O strastech prechodu muze pojednavat i kurzivou sazena poznamka zde
> 	http://www.linuxzone.cz/index.phtml?ids=3&idc=908 .

Myslite toto:
"Pro nezasvěcené: I přes to, že samotné jádro podporuje už od Linuse jiné
platformy, je potřeba poměrně dost záplat na to, aby opravdu spolehlivě na
těchto platformách vše fungovalo a poskytovalo běžné vymoženosti. Například
i pro AMD64 chybí jádru z FC1 poměrně dost netriviálních záplat, které je
potřeba z jádra v RHEL přeportovat z verze 2.4.21 na verzi 2.4.22 nebo je
přebrat z novějších verzí upstreamu. Podrobnosti viz archiv listu
fedora-devel zde a zde. Podobně mohou být potíže i se staršími nebo HW
závislými aplikacemi."

Videli Ste kolko zaplat ma RH/Fedora v kernelu pre i386? A snad nikto
nepochybuje, ze je ten kernel 32-bitovy. Tu sa jedna o port na inu
architekturu a nie len o 64-bitovy kernel.


> > perspektivy. Napokon mam pocit, ze 64-bitovy linux na Alphach 
> > uz niejaku tu
> > dobu bezi.
> 
> 	O tom se nepru - pidim se vsak po realne efektivite tohoto
> 	procesu/provozu...

Tak si mozte realne a efektivne kupit 64 bitovy oracle/DB2, instalovat 8GB
pamate a tesit sa z toho, ze aky velky proces si dokazu vytorit a kolko toho
drzia v pamati.

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

				jano

--