31
-
shabba #31 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. -
#30
Köszönöm a kimerítő választ!
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? -
shabba #29 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. -
#28
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.
Áááá mindegy, nem értek én ehhez :) -
shabba #25 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) -
#24
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. -
shabba #23 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. -
#22
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 -
#20
Ilyen esetekben pedig az üzemmódok közötti váltás jelent időveszteséget :) -
#18
Meg sok esetben csökkenést is, pontosan a nagyobb adatok felesleges mozgatása miatt. -
#16
Nah, ez orom ;> - mar csak motivacio kell a gepbovitesre... meg persze az apro elhanyagolhato kis penz. -
#10
az itanium kifejlesztése tengernyi pénzt vitt el, meg lehet nézni milyen sebességgel képes az x86 kód futtatására évek multán is ... -
![[HUN]PAStheLoD](https://media.sg.hu/forum/avatars/10334754621140968716.jpg "[HUN]PAStheLoD")
#9
majd m$ ék a longhorn-al besegítenek ... -
shabba #8 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. -
Mice #6 szerintem kettő lesz az, jövő ilyenkorra szerintem még mindig alig lesznek rá sw-ek -
Gabest #5 Szerintem egy év múlva mindegy lesz, mit akarsz egy otthoni gépbe, ha csak 64 bites cpu-t kapsz már a boltban. -
#4
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 -
#3
"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).
-
sniper #1 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.