128 bites lehet a Windows 8 és 9

"Az opera peldaul kezeli a flash-t mindegy neki,"

Persze mert az opera 32bites így önmaga is emulálva fut, benne egy 32bites flash playerrel. Nincs 64bites opera. Jelenleg csak IEbõl van natív 64bites (nincs is alatta flash), meg FFbõl valami tákolmány (ezalatt sincs flash).

Ez igy kb. OK... de azért mégis csak van különbség ha több bit fér el a regiszterekben 😊 persze nem akkora mint ahogy sokan gondolnák de mégis. A 8088-80286 (és az utodok is részben) memóriakezelésével pedig nem igen kell foglalkozni, ugyanis ott éppen, hogy nagy baj volt a 16 bites regiszter és a 20 bites memóriacímzés... elképesztõ sokat szívtunk annak idején a "szegmentált" memóriacímzésel az offszetekkel, nagyon sok korlátozás volt itt... még nem jött a 32 bites mód a PC szart sem volt képes a szintén 16 bites CPU-kal szemben de amelyeknek 32 bites regiszterei voltak (Apple, Amiga, Atari...) mindég a fél program a memóriával szarakodott és ami még roszabb volt a programozó több idõt töltött (tudom mert csináltam) az adatstruktúrák adaptálására az adott memóriamodelhez és a korlátozások "áthidalására" mint a valódi problémák megoldására. Szóval a több bit jobb, a 128 bit jobb mint a 64 bit... a baj csak ott van, hogy jelenleg nincs rá szükség, ha ezt a fejlõdési ütemet tovább tudjuk produkálni akkor lehet, hogy 10 év múlva majd kell de most jelenleg az ég világon nem tudnánk mit kezdeni vele és ha egy-két pici tartományban esetleg tudnánk akkor meg gazdaságilag nem értelmes mert nagyon sokba kerül a váltás és nincs megtérülés.

32 bites visztán is lehet több ramot elérhetõvé tenni parancssorból csak lassú lesz a ramkezelés mint a rosseb.

Azért kicsit kerüljünk már képbe a mi hány bites ügyben. 8088-as processor, DOS:
16 bites regiszterek
8 bites adatbusz
20 bites címzés
32 bites fájlrendszer
10 bites HDD track szám
6 bites HDD sector/track szám.
9 bites sector/byte szám.
Oszt mégis mûködött, frankón. Az hogy az oprendszer hány bites semmi mást se határoz meg, minthogy a memóriát hány bites címzéssel éri el. Ezt persze a processzornak is tudnia kell, de ennyi. A processzor regiszterei, adatbusz, fájlrendszer, minden-minden hány bitessége ettõl teljesen független. Nem kell összeszarni magunkat attól pl ha csak 16 bites regisztereink vannak, és 32 bitet kell címezni, mivel kb 3 db assembly mûveletbõl össze lehet állítani a címet. Nem ettõl lesz lassú a Crysis, hanem attól, hogy a winfos kiswapeli az agyát, hogy a játék 2G-s fájlos 1x betöltött adatfájlát cachelni tudja.

Lehetett a 16 bites oprendszer (DOS) alatt com fileokat írni, amik 64Kbyte memóriát láttak. Meg lehetett exe-t, amik már 640Kbyte memóriát láttak (holott 1024-et kellett volna a 20 bites címzéssel, de hát ilyen az élet, ahhoz már kellett XMS/EMS, ami meg csak 286-on jött be).

De lehetne arról is beszélni, hogy 32 bites linuxon mit is csinál a PAE kernel. Merthogy ez biztosítja azt, hogy a 4G feletti memória tartományt is ki lehessen használni. Igaz, 1 program továbbra is csak 32 bittel indexelhetõ memóriát ér el, de ha van 16 gigád akkor mondjuk 4x3.5G belefér (kernelnek meg egyebeknek is kell azért memória). Mindezt 32 bites oprendszeren ugyebár.

Az hogy 1 fájl mekkora lehet az abszolúte nem függ attól, hogy az oprendszer hány bites. A DOS 20 bites volt, a file pointerek meg 32 bitesek, alapból, már akkor amikor 360KByteos-s floppy volt a menõ. Fat32 filerendszerben a file pointerek 32 bitesek, tehát rakhatod 128 bites oprendszer alá is, akkor se fogsz benne 4G-nál nagyobb fájlt csinálni. NTFS filerendszerbe meg XP alatt is csinálhatsz 4Gnál nagyobb fájlt. Persze ha egy fos böngészõ ezt úgy akarja, hogy beolvassa az egészet memóriába, és utána egyben kimenti, akkor ott out of memory lesz. De ez programkód gyengeség - 4G memóriát nem foglalunk le buffernek. Aki ilyet tesz el kéne tiltani a programozástól egy életre.

De írhatnál akár te is, mivel az swf formátum már évek óta nyílt. És nyílt formátumra nem csak linux alatt lehet fejleszteni, hanem pl windows alatt is. Senkinek sincs megtiltva.

Fõleg ha nem kis hanem nagy "indián". 😊

Há mer kéccer olyan jó mint a 64-es! 😄

128 bit meg mi a f.sznak?

"Mert linuxon nincs 32bites emuláció, tehát x64-es linuxon nem fut a 32bites program, csak 64bites. Ami nem gond ott ahol nem egy zárt szar fejlesztõjére kell várni(adobe)."

Mondjuk 64 bites linuxon is van 32 bites mod (debian-on legalabbis), csak kevesbe tamogatott mint windows eseten.

"vindózon azért kell várni meg a 32bites is, linuxon meg nem!"

Mindket rendszeren megoldhato a 32 bites plugin futtatasa 64 bites bongeszoben, csak egyik rendszeren sem elegans a megoldas. Az opera peldaul kezeli a flash-t mindegy neki, hogy windows vagy linux es 32 bit vagy 64 bit. Csak nem elegans, nem gyors es nagyon nem stabil ha hack-elni kell valamit.

"Pl engem kifejezetten zavarna ha a böngészõm 2G memóriánál többet használna, vagy ha egy html fájl több mint 2GByte lenne."

Akkor az is zavaro ha egy 4 GByte-nal nagyobb file-t kell letolteni es mukodik, ugyanis egy 32 bites bongeszokon trukkozni kell, hogy ez menjen. 64 bites rendszereken sokkal egyszerubb es stabilabb kodot lehet irni. A nagy meretu kepek es egyeb beagyazott tartalmak kezeleserol nem is beszelve.

Mi van?😄 Milyen HTML fájl? Te mirõl beszélsz?😄 Kevés embernek sikerül ennyi baromságot egy HSZ-ben összehordani. Azért mert valami 64bites nem használ rögtön 2GByte memóriát <#falbav>.

Nem fölényeskedõ vagyok, ezek a száraz tények.

Mi? flash playert az adobe írt linuxra is, senki más.
vindózon azért kell várni meg a 32bites is, linuxon meg nem!

Mert Windowson miért kell várni, ha linuxon nem? Az swf formátum éppenhogy nyílt, ha zavar valakit hogy nincs Windowsra 64 bites, meg lehet írni. Ugyanúgy, ahogy linuxra is megírták.

Szóval szerintem ha ez igazi probléma lesz, akkor fordítanak belõle 64 bites verziót is.

Gondolom a legtöbb ember nem dõl a kardjába azért, mert a böngészõje 32 bites. Pl engem kifejezetten zavarna ha a böngészõm 2G memóriánál többet használna, vagy ha egy html fájl több mint 2GByte lenne.

Mert linuxon nincs 32bites emuláció, tehát x64-es linuxon nem fut a 32bites program, csak 64bites. Ami nem gond ott ahol nem egy zárt szar fejlesztõjére kell várni(adobe).

Hehe "csak idióták használják" azért jónéhány "idióta" profeszor és elõadó használja pl. a Stanford-on és az MIT-en is 😊 ...

64-bites alkalmazást meg csak akkor írnak, ha megvan az igény... most, hogy a Win7-el elég sokan már a 64-bites verziót veszik majd lesz majd értelme megírni a 64-bites alkalmazásokat is, tehát jön az Office 64-biten aztán meg mivel sok más alkalmazás az Office-t veszi példaképnek majd követni fogja ezt. Persze a grafikus és CAD alkalmazások (Photoshop, 3DS MAX, Maya, AutoCAD, CATIA, stb. már megvannak 64-biten mert ott már eddig is megvolt az igény, és megtõrült a befektetés. Mindenesetre néhány év múlva már minden 64-bites lesz ez nem kérdés.

Baromság az egész.
Ma a legerõsebb közös címterû gépekbe 4TB memóriát rakhatunk, bár azon a windows nem is fut.
Ha folytatódik a moore törvény, akkor 1,5-2 évente megduplázódikik a memória mennyiség. A 64 bit elég 16 EB-re, ami 2^22-szer több, tehát még 30 évig biztos elég lesz a 64 bites címtartomány. 30 év múlva a win8/9-re már nem is fog emlékezni senki.

Ha egy gep 64 bites, akkor erdemes a legtobb azon futo programot is hasonloan 64 bitesre irni. Ilyen gyakran hasznalt program peldaul egy webbongeszo. Ha a bongeszo 64 bites lesz, akkor jo ha az osszes plugin-ja is 64 bites, hogy hack-eles nelkul lehessen kezelni oket. Lehet, hogy a flash-nek nincs szuksege a 64 bitre, de sokkal gyorsabba es stabilabba valik ha nativ modon kepes futni az adott hardveren. Most ott tartunk, hogy a 64 bites gepeken a flash miatt hasznalnak regi elavult 32 bites bongeszoket, vagy hack-elgetik a 64/32 bites konverter interface-eket, amik meg raadasul le is lassitjak az egesz gepet. Az adobe igazan osszeszedhetne mar magat...

"Csakhogy a számítógép nem felhasználóbarát. Kicsit sem."

Pedig van olyan is. Pl. a mac-ek nagyon felhasznalobaratak, de mivel ugy terveztek oket, hogy idiotak is tudjak hasznalni, ezert szinte csak idiotak hasznaljak. A windows pedig lehet, hogy nem felhasznalobarat, de megis mindenki tudja hasznalni. Majd ha olyan autokat gyartanak, amiket tanulas nelkul el lehet vezetni, akkor lehet szidni a szamitogepeket. Egyebkent meg a legtobb gond abbol adodik, hogy a felhasznalo belenyul a rendszerbe. Egy autot vagy egy gazkazant sem all mar neki minden tulaj otthon barkacsolni, hanem szerelot hiv. Egy sokkal bonyolultabb windows-os pc eseten miert akar megis mindenki szerelo lenni?

Tán mert nem megy a Flash x86 egyetlen k******t 64 bites böngészõvel sem??? Hmmm?
Azért röhejes, hogy a 64 bites OS-en lévõ 64 bites IE8 vagy Seamonkey, vagy akármi mellé el kell indítani a 32 bites verziót, ha sz*ros flash oldalt akarsz nézni.

Amúgy van 64 bites Flash, béta már 2008 március óta, de nem sokára kijön. De csak Linuxra. Kérdem én miért?

1. Flashben nincs 64 bites változó, tehát 64 bites regisztereket se tudja semmire se használni.
2. Flashben nem ildomos 2G-nál több memóriát használni, tehát címzésre is értelmetlen a 64 bit.
Akkor meg minek?

Ne legyél már ennyire fölényeskedõ

Azért a figyelmetekbe ajánlanám, hogy a normális emberek nem kockafejûek. A felhasználókat nem érdekli a regiszter, mer memóriacímzés, meg 64bit, meg más hasonló marhaság.

A felhasználók úgy akarják használni a számítógépet is mint pl. a televíziót. Bekapcsolja és mûködik. és senkit nem érdekel, hogy belül ez milyen technológián alapszik.

Csakhogy a számítógép nem felhasználóbarát. Kicsit sem. (Errõl leginkább a programozók tehetnek, úgyhogy õk pedig sz@rjanak sünt. <#puszis> )

Egyébként elfelejtettem mondani, hogy egy mai modern CPU-nál kb. 1% tranzisztor (és CPU terület) az ami a tradicionális von Neumann féle CPU vagyis az ami arithmetikát és logikát implementál, a többi 99% pedig nem más mint a lappangási idõ (latency) elleni harc (cache, párhuzamosítás stb.)

Érdekes, hogy az emberek mennyire nem figyelnek erre fel, de már évek óta a fejlõdés óriási része valójában a latency problémának a megoldásában nyilvánul meg. A 64-bites architektúra ebben segített valamit de a fõ elõnye a 32-bites architektúrákhoz a memória címzés tartományának bõvítése... 128-bites architektúra nem járulna majdnem semmit hozzá a latency elleni harchoz a mamória címzés tartomány elméleti bõvítésére pedig jelenleg nincs szükség. A fejlesztés nem ingyen dolog, az erõforrásokat tovább a latency elleni harcra kell fordítani és jelenleg nem tudunk semmi más megoldást mint a cache és a párhuzamósítás további növelését. De itt nem elég csak a hardver, szoftvernek is meg kell változnia... nem hiába fektet az Intel és mások is százmilliókat olyan szoftver fejlesztõi eszközök fejlesztésébe amelyekkel a hardverban lévõ már létezõ és jövõben érkezõ lehetõségeket igazán ki tudjuk majd használni. És az a baj, hogy egy idõ után majd Amdahl törvényébe ütközünk...

Mióta Bill "nyugdíjba" ment, azért elég sok minden változott MS-nél. Lehet nem akarnak a jövõben lemaradni.

Egyébként ez azért is kamu, mivel linuxnál meg más os-nél nem is hallottak még 128bitrõl. Az m$ meg mikor volt úttörõ egy technológiában? soha kb. Mindig hátul kullogva építette bele a dolgait a winbe, miután már máshol ki lett próbálva.

Ezt úgy szeretem! 128 bites LEHET a ws 8-9. Meg a kisf@zsom. Mi nem lehet? Lehet hogy 135.8 bites lesz a következõ architektúra, vagy eljön a vilgágvége. Lehet hogy újra eljön Jézus és lehet tudok venni egy házat hitelre. Lehet ezek mind buzik. Oda kéne írni hogy Lehet 128bites lesz, de kurvára nem biztos! Hülye m$.. takarodjon.
Buntu-Ubuntu

Meg a globálciganyizmus is, viktor elvtárs jövõre visszahozza.

Igen sok 128 bites proci van manapság, létszükséglet a 128 bit támogatása... Vagy majd 2 64 bites mag fog RAID1-ban dolgozni? ^^

64 bites alkalmazásból se sok van, mennyit fognak majd erre írni? Nem mondom hogy hülyeség, mert felõlem lehet egybõl 512 bites is, de akkor használják is ki!

meg Vistahoz is eros gep kellett, a legtobb winhez jo eros gep kellett, mikor megjelent.
a win7 allitolag kivetel.

Azért nem éppen, amikor XP kijött akkor az akkori legjobb gépen nem ment úgy mint ahogy most egy Win7 megy egy pár éves gépen. 98-ra is igaz ugyanez.

A Transmeta chip-jei hány bitesek voltak?

"Múltkor próbáltam az Office 2010-et, amibõl már van natív 64bites, kb. fél mp alatt nyitott meg egy üres dokumentumot, egy 60 oldalasat pedig 1-2 mp alatt dobott be."

Ezért érdemes is fejlõdnie a technikának! 😮

----

Ezt 1999-ban is meg lehetett csinálni ennyi idõ alatt az aktuális worddel, 2009-ben is meg lehet.

10 év alatt fejlõdött valami?
- Gyorsabban megnyílik ma a vezérlõpult?
- Gyorsabban bootol a gép?
- Gyorsabban lehet megnyitni a word doksikat?

NEM

Mindig minden ugyanolyan sebességû. Teljesen mindegy hogy fejlõdik a hardver, a szoftver visszalassítja. Egyedül ott van tényleges gyorsulás, ahol a célalkalmazás bonyolultabb matematikai mûveleteket végez fõ funkcióként (pl. videótömörítés és társai). Ezért hülyeség azt várni, hogy "most jön a Core 16 kvadrillió 65536 bites processzor és akkor majd ilyen meg olyan gyors lesz, 1 mp alatt bootol, kész kánaán..." - igen, akkor is ugyanúgy fogsz malmozni a gép elõtt.

attol fuggetlenul, h a globalcionizmus egy valos fenyegetes, telleg devians a csavo..

Fú, most hogy mondod, tényleg! Ott is ezt a nicket használja?
Akkor visszavonom, nincs a háttérben ms-konspiráció, bár ahogy elõadja, az ms simán fizethetne neki ezért a mûsorért.

Te meg mit idegeskedsz? Hmm?
Szerintem is XP volt a legnormálisabb rendszer, már rendesen kihívást jelent feltelepíteni egy új laptopra az ms ügyeskedése miatt.
Kkkk... 128 bit? pff... érdekesség, hírnek jó, de én aztán marhára letojom. A jelenlegi programok kiszolgálják azt az igényt, amire szükség van. Ennyi.
Egyébként meg MS-nek is kell valamit csinálni, ha most nem tud értelmeset! De tényleg.

Tuti sérült. Nem csak a windows SUXX témában nyomja, hanem globálcionizmus/megfigyelés/összeesküvés-témában is.

Kétesélyes a dolog. Az egyik lehetõség, hogy a fickó mentálisan sérült (mióta bezárták a Lipótot, egy csomó ilyen mászkál szanaszét). Amely esetben nem nevetünk rajta, mert az ilyeneken óvodás dolog nevetni. Akinek van vagy volt valaha ilyen a környezetében, az tudja, miért nem vicces ez.
A másik eset, hogy nagyon is tudatosan csinálja amit csinál. Azt mutatja be, hogy a ms szerint miféle ember az, aki nem akarja win7-et és/vagy liuxot használ. Viralmarketing, huh? Duplacsavar, elismerem, de nem tartom kizártnak.

<#hehe>
Én azt szeretném látni screenshotban, hogy linuxban virtuális gépen fut egy XP és egy Win7 és mindegyiken megy mondjuk a 3dmark. És hogy melyik ér el több pontot... Na ezt szeretném látni. <#idiota>

"Fórumstatisztikák
(...)
Összes fórumozó: 302515 fõ"
...s ennek felét Arrakistor különbözõ inkarnációi teszik ki<#idiota>

Hát ez olyan, mint a mostani 64 bites operációs rendszerek. Nem tudnak annyi memóriát kezelni, mint ami a 64 bit határa. A Vista 64 bit ha jól tudom maximum egyszerre 16 GB-ot tud kezelni. Win7-nél nem tudom.

Mikor fogod fel végre, hogy lõtéri döglött kutyát nem érdekli a faszságod amit ide írkálsz?

Arrakistor?! Még mindig nem tiltottak be téged???

Köszönöm a sulit de nem sok szükségem van rá... egyébként tökéletesen tudom, hogy a Windows már támogat 256 magot de ez messze nem jelenti azt, hogy képes azt optimálisan használni is (mert még véletlenül sem)... ha érdekel a téma ajánlom pl. a HOPL-III keretein mehjelent Erlang-ról szóló szöveget... az igazság ott van, hogy igen sokat tudunk a párhuzamos és konkurens (a kettõ között van némi eltérés) tehnikákról de csak részben és elég kezdetlegesen van ebbõl valami implementálva fõleg szoftver területen.

A von Neumann architektúra tovább is az alap, de a párhuzamosítás ezt nagyon megváltoztatja, az ami normális volt és megszokott a klasszikus von Neumann modelnál már kontraproduktív a multicore-nál... ez tény, ha nekem nem hiszed el el, hidd el Bjarne Stroustrup-nak (akinek egyébként a PhD munkája éppen errõl szólt és aki a C++ faterja) vagy Andrew Koenig-nek (szintén apszolút C++ guru).

A C++-nak semmi baja, a baj ott van, hogy a "C++" programok 90% valójában C amibe bedobnak egy pár dolgot a C++-ból... de ha mégis tudnál valamit amit pl. én nem tudok ezen a téren kérlek ird le, mert olyan, hogy a "C++ nem jó" semmit nem érõ állítás.

Ami a 128 bites filerendszereket vagy IPv6-ot illeti semmi szükség 128-bites architektúrára, ugyan a regiszterek lehetnek 128-bitesek de nem gondolod, hogy óriási költségekkel járna a 128-bites architektúra bevezetése csak azért, hogy egy picit jobban kezelje az IPv6-ost mert más dolgokban nem hiszem, hogy megközelítõleg is ki lehetne használni. Semmi sincs ingyen, létezik olyan dolog, hogy "cost/benefit analysis"... egy dolog megszerkeszteni egy laboratóriumi "játékot" és más dolog valós ipari rendszereket fejleszteni, tudod én szeretem a LISP-et és még jobban a Scheme-t de nem gondolom, hogy ipari rendszereket lehet vele gazdaságosan építeni.

Amit most a kezünkben tartunk a multicore rendszereknél az nem más mint a ZX Spectrum vagy a C-64... az elkövetkezõ években óriásit fog változni a világ a multicore felé olyan fejlesztések és implementációk fognak jönni amilyenrõl a jelenlegi OS-ek, nyelvek és fordítók álmodni sem tudnak és amelyeknek még csak elõfutárait láthatjuk a Windows 7-ben (nagy rész ennek már megvan tudományos munkákban és egyetemen alkalmazott nyelvekben de nincs még implementálva a mainstream technológiákban).

Még valamit... létezik Mort, Elvis és Einstein... találd ki kinek lett a C++ kitalálva 😊

"mert nem tudok elképzelni olyan problémát amelyre a 128 bites architektúra (mint általános CPU) megoldást jelentene."

Az ipv6-os cimek 128 bitesek. Ipv4-nel is jol jon, hogy egy ip cim pont belefer egy 32 bites regiszterbe. Routerekben es egyeb ipv6-ot hasznalo keszulekekben jol jon a 128 bites regiszter. Aztan ott vannak a filerendszerek. 32 bites rendszereken mar most is ket 32 bites rendszerszoban kell tarolni az offset-eket, 64 bites rendszereken ezek pont befernek egy valtozoba, de az uj fejlesztesekhez mar megint ket 64 bites kell, vagy 4 darab 32 bites, ami mar a kezelhetetlenhez kozelit.

"Persze azt sem szabad elfelejteni, hogy 128 bites CPU architektúrákról még elméleti munka sincs egyik CPU gyártó cégnél sem"

Akkor valoszinuleg ezert kerult bele az amd64-es specifikacioba a 128 bites mod lehetosege. Az intel altal megvasaroltban nincs benne, tehat az x86_64-es architektura fejlesztoi kozzul csak az amd foglalkozott vele.

"szerintem a Windows 8 inkább arra fog koncentrálni, hogy vége van a "von Neumann" korszaknak és vége van az "ingyenes ebébnek" ugyanis a multicore az ami jön (ez ami most van ez még csak vékony kis bevezetõ) mert mire a Windows 8 jön az átlag asztalon valószínûleg már 8 mag lesz"

A von neumann architekturanak miert lenne vege, attol hogy tobb processzor lesz? Az adatokkal egyutt tarolt programu vegrehajtast ez nem befolyasolja. 8 magos desktopot meg mar windows xp 64-el is lattam, szovel nem uj technologiarol van szo, csak egyre olcsobb lesz.


"a high-end asztalokon meg 16 vagy annál is több és ezt a Windows 7 (nem beszélve az XP-rõl) már csak nagyon primitív módon fogja tudni kezelni."

A winnt kernelek a vms rendszerek leszarmazottjai. Meg az elod is kezelt 256 magot, erre a winnt kernel is kepes, csak az eladott verziok egy resze limitalva van. (de a winxp pro is 16 magig skalazhato hackeles nelkul)

"Óriási jelenleg a párhuzamos implementációk körüli érdeklõdés (maga a új C++0x szabvány is pl. ezt veszi a legfontosabb dolognak), tehát nem csak az alkalmazás fejlesztések hanem a rendszer fejlesztések és maga a hardware fejlesztések is ebbe az irányba fognak fejlõdni."

A c++-ot nem jo iranyba fejlesztik, egyre bonyolultabb es hasznalhatatlanabb lesz. Parhuzamos gepbol eddig a legnagyobb amit programoztam 65536 magot tartalmazott. Mondjuk arra meg assembly-ben kellett fejleszteni, de a kutatok altal hasznalt fortan nyelv mar regen is eleve jol kezelte a parhuzamositast, de az osoreg c szabvany is alkalmas erre, meghozza modositas nelkul. Az egyetlen amire szukseg lehet az az int128_t es az uint128_t bevezetese lenne a c/c++/c# nyelvekben, akkor az ipv6-os cimeket es a filerendszer offet-eket is lehetne egyetlen nativ valtozoban tarolni.

javítás: ... 128 bites Windows ... (utolsó mondatnban)

Nem tartozok azok közé... de ami a forrásokat illeti olyan dolgok vannak bennük mint pl. IA-128 amely az IA-64 el kompatibilis (az IA-64 az Itanium nem x86, az x86 az AMD64 vagy Intel64 (azelõtt EM64T) néven ismert) tehát ez nem stimmel... fõleg ha tudjuk, hogy az IA-64 nem éppen sikeres a piacon akkor miért csinálna most az Intel vele kompatibilis 128 bites architektúrát? Nem beszélve, hogy a 64 bites softver is még csak most fog elterjedni (én jómagam már majdnem 3 éve 64 bites OS-eken futok de az alkalmazások nagyon kis része 64 bites). És még valamit jelenleg az IBM Roadrunner is csak 64 bites... és ha tudjuk, hogy a szuperszámítógépek esetében kb. egy évtized volt a 64 bites architektúrák elõnye (azért mert ott szükség volt mert a 32 bit már nem felelt meg) akkor nehezen tudom elképzelni, hogy most amikor a szuperszámítógépeknek is elég a 64 bit akkor majd most úgy egy lépésben jön a 128 bites asztali CPU és a 64 bites Windows... szerintem egy nagy félreértés... mint mondtam lehet, hogy csak a filesystem-rõl van szó vagy valami másról.

Annyi, hogy nem értem, miért zavar egyeseket, ha van valami fejlõdés...<#alien2>

Kacsának biztos nem kacsa a hir, mert vannak források.

A logikád szerint már a 486-os 80-bites volt mert az FPU 80-bites registereket alkalmazott...

akkor a mai összes proci is 128bites, hiszen mindben megvan az ami a ps2 processzorát is "128bitessé" tette... a 128bites utasítások(sse). Persze ettõl valójában még olyan messze állnak egy 128bites procitól makó jeruzsálemtõl.