64 bit
Architetture | ||||||||
---|---|---|---|---|---|---|---|---|
4 bit · | 8 bit · | 16 bit · | 24 bit · | 31 bit · | 32 bit · | 64 bit · | 128 bit | |
Applicazioni | ||||||||
8 bit · | 16 bit | 31 bit · | 32 bit · | 64 bit | ||||
Dimensioni dei dati | ||||||||
4 bit · | 8 bit · | 16 bit · | 24 bit · | 31 bit · | 32 bit · | 64 bit · | 128 bit | |
Queste definizioni riguardano principalmente il mondo dei processori x86. Le dimensioni 31 e 48 bit si riferiscono invece, rispettivamente, ai mainframe IBM e all'AS/400. |
64 bit, in informatica, indica che in una data architettura il formato standard di una variabile semplice (intero, puntatore, handle ecc.) è di 64 bit di lunghezza. Generalmente questo riflette la dimensione dei registri interni della CPU usata per quell'architettura.
Il termine "64 bit" può essere usato per descrivere la dimensione di:
- Una unità di dati
- I registri interni di una CPU o della ALU che deve funzionare usando quei registri
- Indirizzi di memoria
- Dati trasferiti per ogni lettura o scrittura alla memoria centrale.
Descrizione
Implicazioni architetturali
Su 64 bit in codice binario si possono rappresentare numeri (anche intesi come informazioni). Benché una CPU possa essere a 64 bit internamente, il suo bus dati esterno o il bus indirizzi possono avere dimensioni differenti, maggiori o minori, e il termine viene spesso usato per indicare anche la dimensione di questi bus. Occorre quindi distinguere tra parallelismo di bus esterno e interno. Un bus esterno a 8 bit non limita il sistema ad operare con dati da 1 byte, ma significa solo che ad ogni ciclo di fetch-execute esso è in grado di accedere ad 8 bit della memoria. Di contro, il parallelismo del bus interno determina in modo radicale le caratteristiche dell’architettura del sistema. Il termine può essere usato anche per indicare la dimensione dei codici operativi presenti nel set delle istruzioni del processore o di altri dati. In mancanza di ulteriori chiarimenti, comunque, un'architettura descritta come "64 bit" ha generalmente i registri del processore larghi 64 bit e gestisce dati di questa dimensione sia internamente che esternamente.
I registri, in un processore, sono generalmente divisi in tre gruppi: interi, a virgola mobile e altri. In tutti i processori general purpose, solo i registri interi sono in grado di contenere puntatori (cioè, l'indirizzo di un qualche dato in memoria). Gli altri registri non possono contenere puntatori da utilizzare per leggere o scrivere la memoria, e quindi non possono essere utilizzati per oltrepassare le restrizioni imposte dalle dimensioni dei registri interi.
La quasi totalità dei processori general purpose (con le importanti eccezioni della architettura ARM e della maggior parte delle implementazioni a 32 bit della Architettura MIPS) odierni hanno integrata al loro interno la gestione della matematica a virgola mobile, che può o meno fare uso di registri a virgola mobile larghi 64 bit per contenere i valori da elaborare. La architettura X86, per esempio, contiene le istruzioni a virgola mobile del coprocessore x87, che usano 8 registri a 80 bit in una configurazione a stack; le versioni successive e l'architettura AMD (a partire dall'Athlon XP), contengono, in aggiunta, anche le istruzioni SSE che usano 16 registri a 128 bit. Per contrasto, la famiglia Alpha a 64 bit definisce 32 registri a virgola mobile da 64 bit in aggiunta ai suoi 32 registri interi a 64 bit.
Limitazioni di memoria
La maggior parte delle CPU sono progettate in maniera da far sì che un singolo registro intero possa contenere l'indirizzo di un qualunque dato all'interno dello spazio di indirizzamento della memoria virtuale. Per cui, il numero totale di indirizzi nella memoria virtuale — la totalità dei dati che il computer può mantenere nell'area di lavoro — è determinato dalla dimensione di questi registri. A partire dagli anni sessanta con il System 360 della IBM, continuando negli anni settanta con (insieme a molti altri) il minicomputer DEC VAX ed infine negli anni ottanta con il processore Intel 80386, si sviluppò un consenso de facto sul fatto che 32 bit fosse una buona dimensione per i registri. Un registro a 32 bit consente di indirizzare 232 indirizzi, o 4 gigabyte di memoria. Nel periodo in cui queste architetture vennero progettate, 4 gigabyte di memoria erano talmente al di là della quantità di memoria normalmente installata da venire considerati sufficienti. Un'altra importante ragione è che 4 miliardi (circa) di indirizzi bastano per assegnare un'unica referenza a molti oggetti fisicamente numerabili in applicazioni come i database.
Col passare del tempo e con la continua diminuzione dei costi della memoria (vedi la legge di Moore), ora dei primi anni novanta, cominciarono ad apparire macchine con quantitativi di RAM vicini ai 4 gigabyte, e l'uso di uno spazio di memoria virtuale maggiore di 4 gigabyte cominciò ad essere richiesto per gestire certe tipologie di problemi. In risposta, un certo numero di aziende cominciò a distribuire nuove famiglie di chip con architettura a 64 bit, inizialmente per i supercomputer e le macchine (workstation e server) di fascia alta. La tecnologia a 64 bit è gradualmente arrivata anche sui normali PC, con il PowerMac (2003) e l'iMac (2004) della Apple che usano entrambi processori a 64 bit (Apple li chiama G5), e l'architettura AMD "AMD64" (che Intel ripropose con scarso successo sotto il nome "EM64T") che si diffonde nei PC di fascia alta. L'arrivo delle architetture a 64 bit incrementa la quantità di memoria indirizzabile fino 264 byte, equivalenti a 16 exbibyte. Una quantità enorme, così come lo erano 4 gigabyte pochi decenni fa.
32 contro 64 bit
Il passaggio da un'architettura a 32 bit verso una a 64 comporta un cambiamento profondo, in quanto la maggior parte dei sistemi operativi deve venire pesantemente modificata per trarre vantaggio dalla nuova architettura. Anche gli altri programmi devono prima essere "portati" per poter sfruttare le nuove funzionalità; i vecchi programmi sono generalmente supportati attraverso una modalità di compatibilità hardware (dove cioè il processore supporta anche il vecchio set di istruzioni a 32 bit), attraverso l'emulazione software, o anche attraverso l'implementazione del nucleo di un processore a 32 bit all'interno del chip stesso del processore (come sui processori Itanium di Intel, che includono un nucleo x86). Una significativa eccezione è l'AS/400, il cui software gira su una ISA (Instruction Set Architecture) virtuale, chiamata TIMI (Technology Independent Machine Interface) che viene tradotta, da uno strato di software di basso livello, in codice macchina nativo prima dell'esecuzione. Questo strato è tutto ciò che bisogna riscrivere per portare l'intero sistema operativo e tutti i programmi su una nuova piattaforma, come quando IBM migrò la linea dai vecchi processori "IMPI" a 32/48 bit ai PowerPC a 64 bit (IMPI non aveva nulla a che fare col PowerPC a 32 bit, quindi si trattava di una transizione più impegnativa del passaggio da un set di istruzioni a 32 bit alla versione a 64 bit dello stesso). Un'altra eccezione significativa è la z/Architecture di IBM che fa girare senza problemi applicazioni con diversi tipi di indirizzamento (24, 32 e 64 bit) in contemporanea.
Benché le architetture a 64 bit rendano indiscutibilmente più semplice lavorare con quantitativi massicci di dati come per il video digitale, nell'elaborazione scientifica, e nei grossi database, ci sono state parecchie discussioni riguardo a quanto esse o le loro modalità 32 bit compatibili siano più veloci, in altri tipi di lavori, rispetto a sistemi a 32 bit di prezzo analogo.
Teoricamente, alcuni programmi potrebbero essere più veloci in modalità a 32 bit. Su certe architetture le istruzioni a 64 bit portano via più spazio di quelle a 32, per cui è possibile che certi programmi a 32 bit possano entrare nella velocissima memoria cache della CPU laddove quelli a 64 non ci riescano. In altri termini, usare 64 bit per effettuare operazioni che potrebbero essere gestite a 32, comporta un inutile spreco di risorse (memoria centrale, cache, ecc.). Comunque, in applicazioni come quelle scientifiche, i dati elaborati spesso usano in maniera naturale blocchi di 64 bit, e saranno quindi più veloci su un'architettura a 64 bit in quanto la CPU è progettata per lavorare direttamente con queste dimensioni piuttosto che costringere i programmi ad eseguire più passi per ottenere lo stesso risultato. Queste valutazioni sono complicate anche dal fatto che durante la definizione delle nuove architetture, i progettisti del set di istruzioni hanno colto l'opportunità per apportare modifiche che vanno a colmare lacune di quello vecchio, aggiungendo nuove caratteristiche tese a migliorare le prestazioni (come, ad esempio, i registri aggiuntivi nella architettura AMD64).
Pro e contro
Un errore comune è quello di ritenere che le architetture a 64 bit non siano migliori di quelle a 32 a meno che non si abbiano più di 4 gigabyte di memoria. Questo non è completamente vero:
- Alcuni sistemi operativi riservano per uso proprio una porzione dello spazio di indirizzamento di ciascun processo, riducendo di fatto lo spazio libero indirizzabile dai programmi. Per esempio le DLL di Windows XP e i componenti di sistema che girano in modalità utente vengono mappati all'interno dello spazio di indirizzamento di ogni processo, lasciando solo 2 o 3 gigabyte (dipende dalla configurazione del sistema) di spazio di indirizzamento disponibile, anche se la macchina ha 4 gigabyte di RAM. Questa restrizione non è presente nella versione a 64 bit di Windows.
- La mappatura in memoria dei file sta diventando sempre più problematica sui sistemi a 32 bit, specialmente dopo l'introduzione di soluzioni economiche per la scrittura di DVD. File da 4 GB sono ormai usuali, e viste le dimensioni la loro mappatura in memoria su macchine a 32 bit è complicata (è necessario tenerne in memoria solo una certa porzione per volta). Questo porta a problemi prestazionali, dal momento che la mappatura in memoria resta uno dei metodi più efficienti per i trasferimenti dal disco alla memoria, quando viene implementata correttamente dal sistema operativo.
Il maggior svantaggio delle architetture a 64 bit rispetto a quelle a 32 risiede nel fatto che gli stessi dati occupano uno spazio leggermente maggiore in memoria (a causa dei puntatori più larghi, altri tipi di dati e allineamenti (i compilatori in genere inseriscono dei byte inutilizzati allo scopo di allineare l'indirizzo dei dati a una qualche potenza del 2, spesso pari al numero di bit dell'architettura). Questo incrementa le richieste di memoria dei programmi, e può avere implicazioni nell'uso efficiente della cache (che ha dimensioni limitate). Mantenere parzialmente un modello di dati a 32 bit è un modo, in genere ragionevolmente efficiente, di gestire la situazione. Infatti, il sistema operativo z/OS, decisamente orientato alle prestazioni, usa questo approccio e costringe il codice eseguibile a risiedere in un numero qualsiasi di spazi di indirizzamento a 32 bit mentre i dati possono opzionalmente risiedere in regioni a 64 bit.
Modelli di dati a 64 bit
Convertire applicazioni scritte in linguaggi ad alto livello da 32 a 64 bit presenta diversi gradi di difficoltà. Un problema ricorrente è che l'autore del programma ha dato per scontato il fatto che un puntatore (una variabile che contiene un indirizzo di memoria) ha la stessa dimensione di una variabile di un qualche altro tipo e che sia quindi possibile spostare valori tra i due tipi senza perdere informazioni. Questo assunto è valido su alcune macchine a 32 (e anche su alcune a 16), ma fallisce su architetture a 64. Il linguaggio C e il suo discendente C++ rendono particolarmente semplice compiere questo tipo di errore.
Per evitare questo problema, in C e C++, l'operatore sizeof()
può essere usato per determinare le dimensioni dei vari tipi di dati, nel caso su queste si debbano prendere delle decisioni durante l'esecuzione. Inoltre, i file limits.h (standard C99) e climits (standard C++) danno ulteriori informazioni utili; sizeof() si limita a restituire la dimensione in byte, il che a volte non è sufficiente, perché neanche la dimensione del byte è ben definita in C e C++. È necessario essere prudenti e usare il tipo ptrdiff_t
(nel file header <stddef.h>
) quando si effettuano operazioni di aritmetica dei puntatori; troppo codice usa invece (sbagliando) i tipi "int" e "long".
Né il C né il C++ definiscono la lunghezza in bit di un puntatore, int o long.
In molti ambienti di programmazione su sistemi a 32 bit le variabili puntatore, "int" e "long" sono entrambi lunghi 32 bit.
In molti ambienti di programmazione a 64 bit, le variabili "int" sono ancora lunghe 32 bit, ma le "long" e i puntatori passano a 64. Questo viene descritto come avente un modello dati di tipo LP64. Un'altra alternativa è il modello ILP64 dove anche il tipo "int" passa a 64 bit. Ad ogni modo, nella maggior parte dei casi le modifiche necessarie per migrare del codice verso i 64 bit sono relativamente semplici, e molti programmi scritti correttamente possono essere semplicemente ricompilati senza variazioni. Un'ulteriore alternativa è il modello LLP64 che mantiene la compatibilità con il codice a 32 bit, mantenendo a 32 bit i tipi "int" e "long". Il tipo "long long" ("LL") è ad almeno 64 bit su tutte le piattaforme comprese quelle a 32 bit.
È da notare che il modello di programmazione è una scelta da fare in base al compilatore, e ne possono coesistere più di uno per lo stesso sistema operativo. Comunque in genere prevale il modello utilizzato dalle API del sistema operativo.
Un'altra considerazione riguarda il modello dati usato per i driver. I driver formano la maggior parte del codice presente nei sistemi operativi moderni (benché molti potrebbero non essere in esecuzione mentre il sistema operativo sta girando). Molti driver usano pesantemente i puntatori ed in certi casi devono caricare puntatori di una dimensione precisa nei registri hardware di gestione del DMA. Per esempio, un driver per un dispositivo PCI a 32 bit che necessiti che quest'ultimo carichi in memoria dati ad un indirizzo oltre la barriera dei 4 gigabyte non potrebbe portare a termine l'operazione poiché il puntatore è troppo grande per essere contenuto nei registri del dispositivo. Il problema si risolve facendo sì che il sistema operativo tenga in considerazione le restrizioni del dispositivo al momento di generare le richiesta DMA.
Diffusione
Già nel 2006 le CPU a 64 bit erano comuni nei server e si stavano diffondendo anche nell'ambito dei personal computer (precedentemente a 32 bit), con le architetture AMD64, EM64T e PowerPC 970. Negli anni successivi tale diffusione è stata accelerata dalla necessità sempre più pressante di superare il limite di 4 gigabyte di memoria centrale che la tecnologia dei 32 bit impone.
Oltre i 64 bit
64 bit sembrano sufficienti per la maggior parte degli utilizzi. Si può tuttavia menzionare che l'IBM System/370 utilizzava numeri a virgola mobile di 128 bit, e che ormai anche molti processori moderni li supportano. Il System/370 è da notare, comunque, in quanto usava anche numeri decimali a lunghezza variabile fino ad un massimo di 16 byte (cioè 128 bit).
L'OS/400 usa da anni puntatori a 128-bit. Le applicazioni sono progettate per girare su una macchina virtuale, e poi convertite al set di istruzioni nativo una volta installate. L'hardware originale era un sistema CISC a 48-bit simile al System/370. L'hardware odierno è un PowerPC a 64 bit. Un'eventuale transizione futura a 128 bit sarebbe indolore.
Cronologia
- 1991: MIPS Technologies produce la prima CPU a 64 bit, in qualità di terza revisione della loro architettura (di tipo RISC) MIPS, il modello R4000. La CPU viene resa disponibile nel 1991 e usata nelle workstation grafiche SGI a cominciare dalla serie Crimson, usando la versione a 64 bit del sistema operativo IRIX.
- 1992: La Digital Equipment Corporation introduce l'architettura DEC Alpha nata dal progetto PRISM.
- 1994: Intel annuncia i suoi piani per l'architettura a 64 bit IA-64 (sviluppata congiuntamente con HP) succeditrice dei suoi processori a 32-bit (IA-32). Il lancio è previsto per il 1998-1999.
- 1995: HAL Computer Systems (di proprietà della Fujitsu) lancia delle workstation basate su CPU a 64 bit, la prima generazione dello SPARC64 progettata indipendentemente da HAL. Escono i sistemi AS/400 della IBM a 64 bit che grazie alla loro particolare architettura (il set di istruzioni TIMI) sono in grado di convertire tutto il vecchio software a 32 bit in software nativo a 64 bit senza bisogno di ricompilarlo.
- 1996: Sun e HP mettono in commercio i loro processori a 64 bit, lo UltraSPARC ed il PA-8000. Sun Solaris, IRIX, e altre varianti di UNIX continuano ad essere i sistemi operativi a 64 bit più utilizzati.
- 1997: IBM mette in commercio i suoi processori a 64 bit della serie RS64.
- 1998: IBM mette in commercio il suo processore a 64 bit PowerPC.
- 1999: Intel pubblica il set delle istruzioni relativo all'architettura IA-64. Prime notizie sulle estensioni a 64 bit (x86-64) per l'architettura IA-32 da parte di AMD.
- 2000: IBM mette in commercio il suo primo mainframe a 64 bit, lo zSeries z900, ed il nuovo sistema operativo z/OS — portando al culmine il maggior investimento nello sviluppo di una CPU a 64 bit nella storia e spazzando via istantaneamente i sistemi compatibili a 31 bit prodotti da concorrenti quali Fujitsu/Amdahl e Hitachi. Sistemi zSeries con a bordo Linux seguono velocemente.
- 2001: Intel mette infine in commercio la sua linea di processori a 64 bit, ora chiamata Itanium, puntando al mercato dei server di fascia alta. A causa dei continui ritardi nella sua distribuzione, Itanium delude le aspettative e si trasforma in un fiasco. Linux è il primo sistema operativo a girare sul processore al momento del suo lancio.
- 2002: Intel introduce l'Itanium 2, successore di Itanium.
- 2003: AMD mette in commercio il processore a 64 bit Opteron e la linea di CPU Athlon 64. Anche Apple mette in commercio CPU PowerPC a 64 bit grazie ad IBM e Motorola, insieme ad un aggiornamento del suo sistema operativo macOS. Diverse distribuzioni Linux escono con il supporto all'architettura x86-64. Microsoft annuncia lo sviluppo di una versione del suo sistema operativo Windows per i chip AMD. Intel resta sulla sua posizione di supporto ad Itanium come suo unico processore a 64 bit.
- 2004: Intel, in reazione al successo dell'architettura a 64 bit AMD, ammette lo sviluppo di un clone delle estensioni x86-64, che chiama EM64T. Versioni aggiornate delle famiglie Xeon e Pentium 4 che supportano le nuove istruzioni entrano in commercio.
- 2005: In marzo, Intel annuncia che il suo primo processore dual-core verrà commercializzato nel secondo trimestre del 2005 con la distribuzione del processore Pentium Extreme Edition 840 e i nuovi chip Pentium D. I processori dual-core Itanium 2 seguiranno nel quarto trimestre.
- 2005: Il 18 aprile, Beijing Longxin svela la sua prima CPU compatibile con le specifiche x86-64, chiamata Longxin II. Il chip di circa 2,5 centimetri quadrati contiene 13,5 milioni di transistor, con una capacità di picco di due miliardi di operazioni al secondo e di un miliardo rispettivamente con virgola mobile a singola precisione e con doppia precisione. La massima frequenza è di 500 MHz ed il consumo va da 3 a 5 watt.
- 2005: Il 30 aprile, Microsoft mette in commercio Windows XP x64 Edition per i processori x86-64.
- 2005: A maggio, AMD mette in commercio la famiglia di processori dual-core Athlon 64 X2 pensati per i desktop. I processori Athlon 64 X2 (Toledo) contengono due nuclei con 1 MB di cache L2 per nucleo e sono composti da circa 233.2 milioni di transistor. Sono grandi 199 mm².
- 2005: In luglio, IBM annuncia il suo nuovo processore dual core a 64 bit PowerPC 970MP (nome interno Antares).
- 2013: Il 10 settembre Apple presenta ufficialmente il primo telefono (iPhone 5S) con architettura a 64 bit inclusa nel chip Apple A7
Architetture a 64 bit
Le architetture a 64 bit comprendono (2005):
- L'architettura DEC Alpha (vedit ALPHA 64-bit timeline.)
- L'IA-64 della Intel (usata nelle CPU Itanium)
- L'AMD64 dalla AMD (usata nelle CPU Opteron, Athlon 64, Turion e Sempron 64)
- Intel ora propone la stessa architettura per i propri processori sotto il nome EM64T.
- L'architettura SPARC (a 64 bit dallo SPARC V9)
- L'architettura UltraSPARC della Sun
- L'architettura Sparc64 della Fujitsu
- L'architettura POWER della IBM
- L'architettura PowerPC di IBM/Motorola (in origine il PowerPC 620, più recentemente PowerPC 970)
- L'architettura z/Architecture della IBM, usata sui mainframe IBM z/Series
- Le architetture MIPS IV, MIPS V, e MIPS64 della MIPS Technologies
- La famiglia PA-RISC della HP (a 64 bit dal PA-RISC 2.0)
Voci correlate
Collegamenti esterni
- (EN) Denis Howe, 64 bit, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL
- Porting to 64-bit GNU/Linux Systems, by Andreas Jaeger from gcc summit 2003 (PDF). URL consultato il 3 febbraio 2018 (archiviato dall'url originale il 15 luglio 2004).. An excellent paper explaining almost all practical aspects for a transition from 32-bit to 64-bit.
- 64-Bit Support Computerforum, su 64bitsupport.com. URL consultato il 24 maggio 2005 (archiviato dall'url originale il 9 marzo 2006).
- Data Size Neutrality and 64-bit Support, su usenix.org.
- What You Need To Know About The Shift to 64-Bit Computing, su windowsnetworking.com.
- Henry Spencer's 10 Commandments for C Programmers (archiviato dall'url originale il 6 marzo 2005). menziona esplicitamente la portabilità verso i 64-bit
- Fujits...Who? - A Primer on Fujitsu's SPARC Heritage, su sparcproductdirectory.com.
- China's First 64-bit CPU, su chinaembassy.org.ro. URL consultato il 12 settembre 2005 (archiviato dall'url originale il 25 dicembre 2005).
![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Computer_n_screen.svg/24px-Computer_n_screen.svg.png)