AMD64 - kdo doda HW?

Karel Zak zakkr na zf.jcu.cz
Úterý Listopad 25 12:59:44 CET 2003


On Tue, Nov 25, 2003 at 11:31:37AM +0100, Jan Kasprzak wrote:
> Pavel Janoušek wrote:
> :  Vy  povazujete prechod  32 ->  64 za  hladky, ja  nikoliv, nejen  z
> :  duvodu historickych zkusenosti.
>
> 	Nezapomente, ze v dobe 16-bitovych systemu byla vetsina veci psana
> v assembleru. Dnes kdy jednak mam programy ktere uz davno na 64-bitovych
> systemech bezi a jednak jsou psany v C nebo v necem vyssim, staci uplne
> to, ze se v hlavickovych souborech zmeni definice typu off_t, ssize_t
> a podobnych a nemusim zadnou 64-bitovost resit. Nechapu proc by me jako
> programatora melo zajimat, jak velky mam int nebo long (tedy v pameti;

 Ono hodne jde to jakou kazen mel programator. Neni pochyb, ze na urovni
 knihoven to  je/bude snadne,  ale nebyl  bych si jist  jak moc  lidi si
 dava  pozor na  to kde  a  jak pouziva  int na  misto nejake  presnejsi
 definice. Ostatne peknym  prikladem neceho podobneho, muze  byt podpora
 velkych (rozumej vetsich nez sizeof(int)) souboru v ruznych programcich
 a utilitach (napriklad v "mc") a ne moc nedavna nutnost oprav prave z
 duvodu neutuchajici lasky mnoha lidi k prostemu "int" :-)

 Jinak  souhlas, u  vetsich  a  dnes jiz  portovanych  aplikaci bych  to
 nevidel jako  problem. Daleko vice bych  se bal programu, kde  je sotva
 nejake ./configure.

> : > unsigned long velka_pamat;
> : > ...
> : > if ((m = malloc (velka_pamat)) == NULL)
> : >   printf ("nemozem alokovat pamat");
> : > else
> : >   nacitavam_velke_data(m);
> : > 
> :  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);
> 
> 	Long je v ANSI C definovan jako nejvetsi numericky typ, se kterym umi
> CPU efektivne pracovat. Prasacke to neni, ale lepsi by bylo pouzit size_t.

 Je  to uplne  jedno  pokud mate  jistotu jake  hodnoty  do te  promenne
 ukladate. Jistotu nemate  pokud volate  nejake externi veci  jako treba
 stat().

> :  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...
> 	sizeof(size_t)
> 
> :  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)...
>
> 	Intel C nelze pouzit proto, ze zdrojaky kernelu obsahuji spoustu
> GCC-specifickych konstrukci (jak udelate v Intel C pametovou barieru?
> Jak reknete ze tato funkce ma jit do jine sekce nez ".text"?).

 Bylo by vubec zajimav prohnat vetsinu GNU software jinym kompilatorem
 nez GCC, mozna by se naslo par gcc-ismu i v jinych vecech.

> PS.: Zalamujte zpravy na <80 znaku (jak je napsano i v Meta-FAQ),
> 	neda se to po Vas cist.

 Nemluve o tom, ze uz mu to bylo receno asi 100x :-)

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/


Další informace o konferenci Linux