64-bitine arvutiarhitektuur

Arhitektuur

Protsessori registrid on tavaliselt jaotatud mitmesse rühma: täisarvud, murdarvud, SIMD (Single instruction, multiple data), kontrollsummad ja (vanemates disainides) spetsiaalsed registrid aadresside ja indeksite jaoks. Moodsamates protsessorites saab mälu adresseerimiseks kasutada ainult täisarvu- ja/või aadressiregistreid. Nende registrite suurus limiteerib tavaliselt otseselt adresseeritava mälu hulga, isegi kui protsessoris on laiemaid registreid, näiteks murdarvude registrid.
Enamuses suure jõudlusega 32-bitistes ja 64-bitistes protsessorites (mõned erandid on ARM ja 32-bitised MIPS protsessorid) on sisse ehitatud eraldi murdarvudega opereerimiseks mõeldud riistvara, mis sageli põhineb 64-bitistel andmeüksustel. Näiteks x86/x87 arhitektuuril on instruktsioonid, mis on suutelised laadima ja hoidma mälus 32-bitiseid ja 64-bitiseid murdarve, kuid protsessorisisesed andmestruktuurid ja registrid võivad olla ka 80 bitti laiad.

Piirangud

Enamik 64-bitiseid mikroprotsessoreid on tänapäeval piiratud mälu mahult, mida nad tegelikult suudavad edastada. See on tunduvalt madalam võrreldes sellega, milleks 64-bitine protsessor tegelikult suuteline oleks. Näiteks AMD64 arhitektuuril on 52-bitine piirang füüsilisele mälule ja toetab ainult 46-bitist virtuaalset aadressiruumi. See on vastavalt 4 PB (4×10245 baiti) ja 256 TB (256×10244 baiti). Arvuti ei saa sisaldada 4 petabaiti mälu aga AMD suured serverid, ühismälu klastrite ja muude viisidega võivad selleni jõuda lähitulevikus. 52-bitine mäluaadress annab võimaluse laiendamiseks palju odavamalt kui 64-bitine mäluaadress. 48-bitine virtuaalmäluaadress tehti ka selleks, et võimaldada enam kui 64 000 korda suuremat mälu 32-bitise piirangust, mis on 4 GB (4 × 10 243 baiti). Võimaldades ruumi laienemiseks lähitulevikus ilma, et sellega kaasneks töötlusaja pikenemist täieliku 64-bitise protsessori puhul.

32-bitine vs. 64-bitine

Üleminek 32-bitiselt 64-bitisele arhitektuurile on olnud vaevarikas, kuna enamik operatsioonisüsteeme ja draivereid tuleb uuest arhitektuurist kasu saamiseks ümber kirjutada. Ka tarkvara tuleb uute võimaluste ärakasutamiseks muutma. Vanem tarkvara on tavaliselt toetatud kas riistvara ühilduvuse režiimis (uued protsessorid toetavad seeläbi ka 32-bitiseid rakendusi), läbi tarkvaralise emulaatori või tegeliku 32-bitise tuuma sisestamisega 64-bitisesse protsessorisse (näiteks Itaniumi protsessorid, mis sisaldavad ühte x86 protsessori tuuma, et käitada 32-bitiseid rakendusi). Praegused 64-bitised operatsioonisüsteemid toetavad üldiselt nii 32- kui ka 64-bitiseid rakendusi.
Üks suur erand on AS/400, mille tarkvara töötab virtuaalsel ISA-l, mida kutsutakse TIMI-ks (Technology Independent Machine Interface), mis on tõlgitud koodiks madala otsa tarkvara poolt enne käivitamist. Madala otsa tarkvara ongi see, mida on vaja, et kirjutada ja liigutada kogu operatsioonisüsteem ja tarkvara uuele platvormile. Näiteks IBM tegi oma 32/48-bitisest "IMPI" instruction setist 64-bitise PowerPC.
Kuigi 64-bitine arhitektuur teeb vaieldamatult kiiremaks töö valdkondades nagu videotöötlus ja suured andmebaasid, on pidevalt käimas vaidlused, kas samas hinnaklassis 64-bitised protsessorid on oma 32-bitistest alternatiividest kiiremad ka teistes valdkondades. Igal juhul on X86-64 arhitektuuriga võimalik sujuvalt kasutada enamikku 32-bitiseid operatsioonisüsteeme ja rakendusi.
Kompileeritud Java programmid toimivad ühtmoodi nii 32- kui ka 64-bitises operatsioonisüsteemis. Kuna pikkused ja täpsus on kõikidel sisseehitatud tüüpidel määratud Java standarditega, ei sõltu Java allolevast arhitektuurist. Java programmid, mis töötavad 64-bitises Java virtuaalarvutis, omavad lihtsalt ligipääsu suuremale aadressiruumile.
Kiirus pole ainuke tegur, millega 32-bitiseid ja 64-bitiseid protsessoreid võrreldakse. Rakendused, kus kasutatakse multitegumtööd, klasterdamist ja stress testingut, töötavad paremini 64-bitisel arhitektuuril. 64-bitised arvutiklastrid on just sellel põhjusel laialdaselt kasutusel sellistes suurettevõtetes nagu IBM, HP ja Microsoft.