Ez az új m$ oprendszer natív 64bites lesz és képes futatni az új natív 64b bites programokat de a régi 32bites módra írt proggyk futattására is képes a kompatibilítás érdekében. Én úgy emléxem ezt a két módot lehet 64bites környezetben elõcsalogatni így a régi 16bites dos/win programokat végleg el kell felejteni vagy maximum lesz valami softwares emuláció. Aztán lehet hogy ezt meg én tudom rosszul, anno már régen néztem át egy AMD-s pdf-et és ilyen emlékeim maradtak.
Azért ezek az új processzor üzemmódok nagyobb változtatások egy SSE féle új utasításkészletnél, ezért is készül hozzá új op.rendszer és ezért lesznek hozzá új programok. A nagy elõnye hogy hardweresen kezeli a régi 32biten megírt programokat így kevésbé fájó pont a váltás, fokozatosan lehet lecserélni a meglévõ softwareeket.
Akkor ha jól értem, akkor a közeljövõben nem a natív 64 bites mód fog érvényesülni, hanem fõként a 32 bites stackkel rendelkezõ, de 64 bites regiszterek használatát is megengedõ mód. Ebben az esetben tekinthetõ úgy ez az egész 64 bites dolog, mintha egy újabb MMX, SSE, 3DNow! kiegészítéssel látnák el a procikat?
Persze azzal a megkötéssel, hogy a natív 64 bites mód többre hivatott, bár nem használható a jelenlegi 32 bites programokkal újrafordítás nélkül. Jól gondolom?
Az üzemmódok a kompatibilítás megõrzése érdekében vannak. Az utasításkészletet prefixekkel viszonylag 1xûen lehet kompromisszumok nélkül bõvíteni de nagyobb változtatásokhoz(pl. virtuális memória, 32/64 bites címzés) kellenek az új üzemmódok.
Pl. 16 bites real mode esetén 64KB volt egy szegmens mérete, nem volt virtuális memóriakezelés, a stack kelezés is 16 bites volt. Egy MOV AX,[BX] esetén ha használtad a 32bites prefixet akkor már MOV EAX,[EBX] lehetett a végrehajtandó utasítás de attól a 64KB-os szegmenhatás ugyanúgy megmaradt így hiába volt EBX-ben 64k feletti érték.
Natív 32 bites üzemmód esetén prefix nélkül a 32 bites regiszterek használata a default és a prefixáltakkal érhetõ el a 16 bites régi regiszterek. A virtuális memória kezelése a hardwaresen támogatt lapkezés által lehetõvé vált.
64 bit esetén hasonló váltás történik a kompatibilítás érdekében, prefixekkel használhatók a meglévõ 32 bites regiszterek 64 bites változata de ugyanúgy továbbra is 32 bites a stack felépítése és 32 bites a megcímezhetõ terület hogy a meglévõ programok változtatás nélkül futtathatóak legyenek. Natív 64 bites módban lesz lehetõség a további 8 általános célú regiszter használatára és a 8db további 128bites multimédia regiszter is elérhetõ lesz. A stack szervezése is 64 bites lesz ahogy a memóriacímzés is. A szegmensregiszterek kezelésében is van némi változás. Ezért kell újrafordítani a programokat lehetõleg egy olyan compilerrel ami optimális kódot fordít és kihasználja az új üzemmódban rejlõ többlet lehetõségeket.
Ha ez mind ilyen szép és jó, akkor viszont minek az a sok üzemmód? Elvégre a régi programok úgysem ismerik az új utasításokat, a régieket pedig ismeri az új proci. Akkor tehát menni kellene a régi programoknak is mindenféle hókuszpókusz nélkül 64 bites üzemmódban is.
Szerintem te a processzor üzemmódokkal kevered. Régen volt asszem 4 fajta(én is már jó rég programoztam utoljára asm-ben) real mode a 16 bites, meg a 32 bitesnek is volt több fajtája. Most ha jól tudom 2 új 64 bites mód lett. Természtesen taszk váltáskor lehet váltani ezek között de azért ez nem az amit te leírtál, taszkváltás nincs minden gépi kódú utasítás végrehajtása során.
A kezdteknél volt pl. akkumulator regiszter 16 bites volt AX, ennek volt az alsó 8 bitje AL, a felsõ 8 meg AH. Aztán 386-nál ez a regiszter 32 bites lett EAX, de az alsó 16 bitje ugyanúgy megmarad AX és AH,AL is ugyanúgy elérhetõ maradt. Most a 64 bites módben lett RAX aminek az alsó 32 bitje EAX és a többi alábontás is ugyanúgy él tovább. Különbözõ utasítás prefixek jöttek be az idõk során így volt lehetséges a bõvítés. Az utasítás dekódolás során ezen a prefixek nem lassítanak(ezért is vannak olyan hosszú soklépcsõs feldolgozású procik)
Programoztam Assemblyben, de nagyon alapfokon az tény. Soha nem is szerettem :)
Na mindegy. Lehet égõ meg hülyeség, amit gondolok, de valahogy akkor sem korrekt itt minden. Nem tudom elképzelni, hogy minden veszteség nélkül lehessen egymás után használni 32 és 64 bites utasításokat. Persze ettõl függetlenül még lehet, hogy így van, nem én tervezem a procikat.
Ez hülyeség Pheel, szerintem most zárt rövidre ezt a vitát mielõtt még jobban leégeted magad. Látszik hogy sosem programoztál assemblyben. Pont azért vannak 64 bittõl eltérõ méretû regiszterek hogy címezhetõ legyen kisebb tartománya is regiszternek.
Túlzott gyorsulást nem a 64 bit fog okozni az csak nagyobb adatok mozgatásánál a memoban jelenthet elõnyt, elágazás, iteráció esetén sok elõnyét nem veszed. A 64 bites üzemmód egyik igazi elõnye ami sebesség növekedés okoz hogy 8-cal több általános célú és 8-cal több 128bites multimédia regiszter van, ha ezekre is optimalizálnak a jõvõbeli fordítóprogramok akkor hozhak pár százalék sebesség többletet. De ezt a gyorsulást nem a 64bitesség okozza, ha egy új 32 bites mód lett volna hasonló többlettel regiszterekkel annak is ugyanilyen gyorsító hatása lenne megfelelõ kód optimalizáció után.
A 64 bit igazi elõnye a 4GB-nál több megcímezhetõ memória viszont a vásárlóközönség csupán egy kis részének a szervereket üzemeltetõknek fog igazi elõnnyel járni már ha egyáltalán épp szükségük van erre a többletre, de a home és üzleti felhasználók szinte 99%-a számára totál közömbös lesz ennek a fjúcsörnek a beépítettsége hisz úgy sem fog 8 meg 16GB memóriát a gépébe pakolni még jó ideig, a 4GB még nagyon sokáig elég lesz.
Ha egy regiszter 64 bites, akkor hiába akarsz te oda csak 32 bitet másolni, az akkor is 64 bitet fog írni, ha másért nem, hát hogy kinullázza a felsõ biteket. Kapisgálod? :-P
Olyanból felesleges lenne mégegyet kitalálni hisz már évek óta a piacon van, Intel Itanium a neve.
A 64 bites rendszerek átlag felhasználói körökben nem fognak egy hamar elterjedni. A cégek nem fognak késztetést érezni arra hogy lecseréljék az operációs rendszert és programjaikat 64 bitesre, hisz számukra érdektelen fjúcsör halmazt vonultat fel. 1xûen a hétköznapi használat során nem korlát a maximum 4GB megcímezhetõ memória. Persze idõvel mindenki rá lesz kényszerítve a váltásra ahogy azt már megszokhattuk, de önszántukból nem fognak tolongani a cégek sem az otthoni felhasználók.
legalább elkezdõdött és már lehet is kapni (nem is olyan drágán) x86-64 es CPUkat , az intel féle gondolom még 1 lépéssel jobb lesz ... aztán megint AMD .. és haladunk
"akár 1 év is eltelhet még, mire teljesen általánossá válik a 64 bit a mainstream szegmensben is."
Akár? Szvsz jóval több, mint 1 év fog eltelni az _általánossá_ váláshoz. Az irodai gépekbe jó ideig elég még a 32 bit, de talán otthonra is (kivéve persze a játékgépeket).
Ez 1felol jo dolog, mer legalabb ebben nem lesz 2 kulon szabvany ala DVD, ugyanakkor szar, mert megint nem sikerult levaltani az x86-ot, hurcoljuk tovabb annak elavult, lassito maradvanyait. Rovidtavon nyero, hosszutavon katasztrofa.
Informatika és tudomány
