AMD64 - kdo doda HW?

[Jan Kasprzak]

Pavel Janoušek wrote:
: > -----Original Message-----
: > 	Nezapomente, ze v dobe 16-bitovych systemu byla vetsina 
: > veci psana
: > v assembleru. Dnes kdy jednak mam programy ktere uz davno na 
: 
: 	Chcete rici, ze v 80.-tych letech byl aplikacnim vyjadrovacim prostredkem zejmena ASM (je jedno, na jake platforme)? S timto nazorem se bohuzel neztotoznuji...
: 
	Mluvime jeste porad o operacnich systemech? Pokud ano,
tak na svem tvrzeni trvam.

: > musim pouzivat typy explicitni delky jako uint32_t). Podle meho nazoru
: > ve svete PC bude prechod 32->64 bitu _vyrazne_ jednodussi 
: 
: 	Ale ja jsem netvrdil opak. Jako praci pro kompilator bych si to vsak oznacit netroufl ani v nejmensim...
: 
	Ale ano, je to jen prace pro kompilator - ta rucni prace jiz byla
povetsinou davnou udelana.

: > : 	No ona Alpha byla taky jen 32-bit po urcitou dobu...
: > 
: > Coze? Neplacejte nesmysly. Alpha je od zacatku 64-bitovy 
: > procesor (tim myslim
: > ze ma registry velke 64 bitu, umi delat 64-bitove aritmeticke operace,
: > ma 64-bitovy virtualni adresni prostor, atd).
: 
: 	Byl jsem spatne pochopen, Alpha se na venek tvarila jako 64-bit ve vsem, interne tomu vsak vsude nebylo... 
: 
	Tak to si asi nerozumite (Vy sam se sebou) v definici toho co je
n-bitovy procesor (viz Vase drivejsi poznamka o 8088 a 80386sx).

: > 	Long je v ANSI C definovan jako nejvetsi numericky typ, 
: > se kterym umi
: > CPU efektivne pracovat. 
: 
: 	??? Jak jsem dosel na toto? Zejmena to efektivni zpracovani via CPU? ANSI C prekladac byl i pro I80286 ci I8086/I8088 a presto efektivne s 32-bit cislem pracovat CPU neumel (ANSI C89 long definuje) a to tak ze vubec, potreboval na to specialni HW, ktery s CPU mel pramalo spolecneho (narazim na matematicky koprocesor)
: 
	A long na tech pocitacich byl 32-bitovy? Ja si myslim ze norma o delce
typu long nic nepravi, jen ze 1 == sizeof(char) <= sizeof(short) <= sizeof(int)
<= sizeof(long).

: > 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)
: 
: 	Toje ovsem prace pro cloveka, nikoli kompilator...
: 
	Asi nerozumim kam smerujete, nebo co se snazite dokazat/poprit.
sizeof(x) vyhodnocuje kompilator a programator vubec nepotrebuje presne vedet,
jaky bude vysledek.

: > GCC-specifickych konstrukci (jak udelate v Intel C pametovou barieru?
: 
: 	Priznam se, ze nevim co to je pametova bariera, na kterou narazite....
: 
	Tyka se to preskladavani instrukci v procesoru (prectete si
posledni dva clanky Mikulase Patocky na www.root.cz).

: > Jak reknete ze tato funkce ma jit do jine sekce nez ".text"?).
: 
: 	Ale to je snad vec pro linker a ne pro prekladac zdrojoveho kodu v C...

	Je to vec (taky) pro prekladac, pokud toto ma byt receno uvnitr
zdrojoveho textu v C.

: To je soucasti ANSI C normy?
: 
	Nikoliv. Ja jsem mel pocit ze se bavime o tom proc kernel Linuxu nejde
prelozit Intelovskym CC. S ANSI C to nesouvisi. Nekdy proste potrebujete udelat
nejake veci, ktere ANSI C nespecifikuje. A pak nezbude nez se vazat na
(pokud mozno dokumentovane) chovani konkretniho kompilatoru.

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
|  I actually have a lot of admiration and respect for the PATA knowledge  |
| embedded in drivers/ide. But I would never call it pretty:) -Jeff Garzik |