AMD64 - kdo doda HW?

Pavel Janoušek janousek na fonet.cz
Úterý Listopad 25 08:33:28 CET 2003


> -----Original Message-----
> From: Jan Derfinak [mailto:ja na mail.upjs.sk] 
> 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.

	Prosim? Od jakziva se brala bitovost podle sirky sbernice CPU a to ve vetsine pripadu DATOVE! (vyjimky jako I8088 a I80386 SX neberu v potaz...) Takze o jakem zlozvyku mluvite, ze neplati?

Datove proto, protoze vetsi prostor nebyl schopen CPU PRIMO naadresovat - leda pres virtualizaci, ktera se zpravidla resila strankovanim.

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

	Nezda - duvod je hned v prvni poznamce.

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

	Zkusim z trochu jineho konce. Oba dva nepochybne pamatujeme (teda pokud nezijete celou dobu v oblasti mainframu...:->) prechod ze 16-ti bitoveho sveta do 32-bitoveho. Tazi se - domnivate se, ze "portace" aplikaci z 16-bitoveho do 32-bitoveho sveta a to, ze realne aplikace zacaly existovat az po vice jak 10 letech od doby, co to umoznovala architektura CPU (a PC vubec) je zapricineno:

a) neexistenci rozumne podpory ze stranu OS, pripadne potreba vytvorit prekladove vrsvy API (napr. Win32s)
b) slozitosti postupu portace
c) studium a vyuka programatoru vyuzivat nove moznosti a postupy
d) mizerna uroven vyjadrovacich schopnosti programatoru
e) mizerna kvalita produkovaneho zdrojoveho kodu

	V podstate vsechny tyto vyse zminene predpoklady byly splneny - DOS a MS Windows vcetne 3.11/Win95 (WinNT 3.1 byl v podstate nepouzitelny OS) nebyly 32-bit, DOS4GW apod. neni zalezitost konce 80.-tych let, programatori se skutecne museli naucit myslet ve 32-bitech. Chcete rici, ze veskery software vyprodukovany v 80-tych letech byl natolik mizerny, ze vyvoj jeho nativni 32-bitove verze musel trvat nekolik let? Co treba profesionalni systemy (zamerne vybiram multiplatformni) jako produkty Adobe, Autodesk apod? Na nativni 32-bitove 3D studio, Photoshop apod. jsme si skutecne museli pockat hodne dlouho, v podstate az do poloviny 90-tych let (10 let!) - jeste kolem roku 1995 AutoCAD (tusim, ze verze 10) potreboval ke svemu behu na Win32 platforme prekladovy modul Win32s!

	Vy tvrdite, ze prechod o jednu generaci "bitovosti" je otazka vzit slusne zdrojaky (ktere jsou psany pro OS o generaci starsi), vzit odpovidajici kompilator, mit k dispozici patricne knihovny a jako vysledek mame optimalni system pro novou generaci. A ja se tazi - kdyz to tvrdite, proc velke mnozstvi firem (ted myslim dodavetele, nikoli zakazniky) investovalo nepredstavitelne sumy penez do prechodu z 16-bit systemu a programu do 32-bitovych, kdyz stacila dle Vas jednorazova investice (pomerne zanedbatelna v porovnani co ten prechod realne stal) a bylo vymalovano...

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

	Chci pracovat s velkymi kusy pameti nebo pracovat optimalne s opravdu velkym souborem/blokem dat a to bez toho, abych musel zjistovat na jak "velke" platforme v tu chvili bezim.

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

	A jak mohu dopredu bez patricnych testu vedet, zda-li mohu (a take jak) pozadat o 8GB? Jak mohu bez testovani dopredu vedet, jak je velky virtualne adresovatelny prostor pro aktualne bezici proces?

Odbocka - docela by me zajimalo, jak to resi JVM, protoze je interne jednak unicodove, jednak (pokud se nepletu) tak 64-bitove. Jak resi tyto limitni stavy na 32-bit platforme?

	Vite, mozna Vas to prekvapi, ale ja jsem i tu teorii studoval (a dostudoval), mozna jsem byl spatny student, tezko rici (necht soudi jini), otazky, ktere tu resime jsme nejak pozapomneli probirat - zrejme jsem byl na spatne skole...

>  
> V takom pripade, je dolezite podla akeho standartu je 
> navrhnuty kompilator,
> aky standard pouziva autor zdrojoveho kodu a ako ho dodrzuju.

	Ve vsech pripadech C a ASM - binding ASM do C je v ANSI norme, ANSI norma C ma od dob K&R 2 revize, GCC "umi" vsechny dialekty (neumi Intel syntaxi ASM, pouze AT&T, ale to neni pricina problemu), Linux kernel je IMHO psan zejmena s ohledem na ANSI C89...

> inej urovni. Jednoducho motor z nakladaku do skodovky asi nepojde. :)

	Skutecne? Pokud budou sedet rozmery, mista vyvodu s okolim, vstupni parametry, mista uchytu apod., tak proc by to neslo? Vy jste nevidel nikdy prebudovane skodovky ci trabanty?

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