64 de biți

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Arhitecturi
4 biți 8 biți 16 biți 24 biți 31 biți 32 de biți 64 de biți 128 biți
Aplicații
8 biți 16 biți 31 biți 32 de biți 64 de biți
Dimensiunea datelor
4 biți 8 biți 16 biți 24 biți 31 biți 32 de biți 64 de biți 128 biți
Aceste definiții privesc în principal lumea procesoarelor x86 . Dimensiunile de 31 și 48 de biți se referă, pe de altă parte, la mainframe-ul IBM și respectiv la AS / 400 .

64 de biți , în informatică , indică faptul că într-o anumită arhitectură formatul standard al unei variabile simple ( număr întreg , indicator , mâner etc.) are 64 de biți în lungime. În general, aceasta reflectă dimensiunea registrelor CPU interne utilizate pentru acea arhitectură.

Termenul "64 biți" poate fi folosit pentru a descrie dimensiunea:

  • O unitate de date
  • Registrele interne ale unui CPU sau ALU care trebuie să funcționeze folosind aceste registre
  • Adrese de memorie
  • Date transferate pentru fiecare citire sau scriere în memoria principală.

Descriere

Implicații arhitecturale

Pe 64 de biți în cod binar pot fi reprezentați numere (destinate și ca informații). Deși un procesor poate fi intern pe 64 de biți, magistrala de date externă sau magistrala de adrese pot fi de dimensiuni diferite, mai mari sau mai mici, iar termenul este adesea folosit pentru a se referi și la dimensiunea acestor autobuze. Prin urmare, trebuie făcută o distincție între paralelismul magistralei externe și cele interne. O magistrală externă de 8 biți nu limitează sistemul să funcționeze cu date de 1 octeți, înseamnă doar că la fiecare ciclu de preluare-executare este capabil să acceseze 8 biți de memorie. Pe de altă parte, paralelismul magistralei interne determină radical caracteristicile arhitecturii sistemului. Termenul poate fi, de asemenea, utilizat pentru a se referi la dimensiunea codurilor de opțiune din setul de instrucțiuni al procesorului sau alte date. Cu toate acestea, în absența unor clarificări suplimentare, o arhitectură descrisă ca „64 de biți” are, în general, procesorul înregistrează 64 de biți pe scară largă și gestionează datele de această dimensiune atât intern cât și extern.

Registrele, într-un procesor, sunt în general împărțite în trei grupe: număr întreg, virgulă mobilă și altele. În toate procesoarele cu scop general , numai registrele întregi sunt capabile să rețină pointeri (adică adresa unor date din memorie ). Celelalte registre nu pot conține pointeri pentru a citi sau scrie memorie și, prin urmare, nu pot fi utilizate pentru a ocoli restricțiile impuse de mărimea registrelor întregi.

Aproape toate procesoarele cu scop general (cu excepțiile importante ale arhitecturii ARM și majoritatea implementărilor pe 32 de biți ale arhitecturii MIPS ) au integrat astăzi gestionarea matematicii în virgulă mobilă, care poate sau nu să utilizeze registrele în virgulă mobilă pe 64 de biți pentru a păstra valorile de procesat. Arhitectura X86 , de exemplu, conține instrucțiunile în virgulă mobilă ale coprocesorului x87 , care utilizează 8 registre pe 80 de biți într-o configurație a stivei; versiunile ulterioare și arhitectura AMD (începând cu Athlon XP ), conțin, de asemenea, instrucțiuni SSE care utilizează 16 registre pe 128 de biți. În schimb, familia Alpha pe 64 de biți definește 32 de registre pe virgulă mobilă pe 64 de biți, pe lângă cei 32 de registre pe 64 de biți întregi.

Limitări de memorie

Cele mai multe procesoare sunt proiectate astfel încât un singur registru întreg să poată păstra adresa oricărei date din spațiul de adresă al memoriei virtuale . Astfel, numărul total de adrese din memoria virtuală - cantitatea totală de date pe care computerul le poate păstra în spațiul de lucru - este determinată de mărimea acestor registre. Începând din anii 1960 cu System 360 IBM , continuând în anii 1970 cu (împreună cu multe altele) minicomputerul DEC VAX și, în cele din urmă, în anii 1980 cu procesorul Intel 80386 , s-a dezvoltat un consens de facto că 32 de biți au fost de dimensiuni bune pentru jurnale . Un registru pe 32 de biți vă permite să adresați 2 32 de adrese sau 4 gigaocteți de memorie. La momentul proiectării acestor arhitecturi, 4 gigaocteți de memorie depășeau cu mult cantitatea de memorie instalată în mod normal, încât era considerată suficientă. Un alt motiv important este că 4 miliarde de adrese (aproximativ) sunt suficiente pentru a atribui o singură referință la multe obiecte care pot fi numărate fizic în aplicații precum bazele de date .

De-a lungul timpului și odată cu scăderea continuă a costurilor de memorie (vezi legea lui Moore ), acum la începutul anilor nouăzeci , au început să apară mașini cu cantități de RAM de aproape 4 gigaocteți, iar utilizarea unui spațiu de memorie virtuală mai mare de 4 gigaocteți a început să fie necesare pentru a gestiona anumite tipuri de probleme. Ca răspuns, o serie de companii au început să lanseze noi familii de cipuri cu arhitectură pe 64 de biți, inițial pentru supercomputere și mașini high-end ( stații de lucru și servere ). Tehnologia pe 64 de biți a ajuns, de asemenea, treptat pe un PC normal, cu PowerMac (2003) și ' iMac (2004) de la Apple care utilizează atât procesoare pe 64 de biți (Apple le numește G5 ), cât și arhitectura AMDAMD64 ” (acel Intel repropus cu puțin succes sub numele „ EM64T ”) care se răspândește în PC - uri high-end. Sosirea arhitecturilor pe 64 de biți crește cantitatea de memorie adresabilă până la 2 64 de octeți, echivalent cu 16 exbibiți . O cantitate imensă, la fel cum erau 4 gigaocteți acum câteva decenii.

32 versus 64 biți

Trecerea de la o arhitectură pe 32 de biți la o arhitectură pe 64 de biți implică o schimbare profundă, deoarece majoritatea sistemelor de operare trebuie să fie puternic modificate pentru a profita de noua arhitectură. Chiar și celelalte programe trebuie mai întâi „ portate ” pentru a profita de noile caracteristici; Programele mai vechi sunt, în general, acceptate printr-un mod de compatibilitate hardware (adică în cazul în care procesorul acceptă, de asemenea, vechiul set de instrucțiuni pe 32 de biți), prin emularea software-ului sau chiar prin implementarea nucleului unui procesor pe 32 de biți, toate cipurile de procesor interne în sine ( ca și pe procesoarele Intel Itanium, care includ un nucleu x86 ). O excepție semnificativă este AS / 400 , al cărui software rulează pe un ISA virtual (Instruction Set Architecture), numit TIMI (Technology Independent Machine Interface), care este tradus, printr-un strat software de nivel scăzut, în codul mașinii native înainte de execuție. Acest strat este tot ce trebuie rescris pentru a aduce întregul sistem de operare și toate programele pe o nouă platformă, ca atunci când IBM a migrat linia de la vechile procesoare "IMPI" de 32/48 biți la PowerPC-uri pe 64 biți (IMPI nu avea nimic de-a face cu PowerPC pe 32 de biți, deci a fost o tranziție mai dificilă decât trecerea de la un set de instrucțiuni pe 32 de biți la versiunea pe 64 de biți a acestuia). O altă excepție notabilă este IBM / z / Architecture care rulează fără probleme aplicații cu diferite tipuri de adresare (24, 32 și 64 biți) în același timp.

În timp ce arhitecturile pe 64 de biți facilitează indiscutabil lucrul cu cantități masive de date precum video digital , procesare științifică și baze de date mari, s-a discutat mult despre cât de compatibile sunt acestea sau modurile lor pe 32 de biți. , în alte tipuri de joburi, comparativ cu sistemele pe 32 de biți la prețuri similare.

Teoretic, unele programe pot fi mai rapide în modul pe 32 de biți. În anumite arhitecturi, instrucțiunile pe 64 de biți ocupă mai mult spațiu decât cele pe 32 de biți, deci este posibil ca anumite programe pe 32 de biți să poată intra în memoria cache a procesorului foarte rapid, unde cele pe 64 de biți nu pot. Cu alte cuvinte, utilizarea a 64 de biți pentru a efectua operațiuni care ar putea fi gestionate la 32 implică o risipă inutilă de resurse (memorie centrală, cache etc.). Cu toate acestea, în aplicații precum știința, datele procesate folosesc adesea blocuri pe 64 de biți în mod natural și, prin urmare, vor fi mai rapide pe o arhitectură pe 64 de biți, deoarece CPU este proiectat să funcționeze direct cu această dimensiune, mai degrabă decât să restricționeze programele. pentru a obține același rezultat. Aceste evaluări sunt, de asemenea, complicate de faptul că, în timpul definirii noilor arhitecturi, proiectanții setului de instrucțiuni au profitat de ocazie pentru a face modificări care umple golurile din vechea, adăugând noi caracteristici care vizează îmbunătățirea performanței (cum ar fi, de exemplu, , de exemplu, registrele suplimentare din arhitectura AMD64).

argumente pro şi contra

O concepție greșită obișnuită este că arhitecturile pe 64 de biți nu sunt mai bune decât 32 decât dacă aveți mai mult de 4 gigaocteți de memorie. Acest lucru nu este în întregime adevărat:

  • Unele sisteme de operare rezervă o parte din spațiul de adrese al fiecărui proces pentru propria utilizare, reducând în mod eficient spațiul de adrese gratuit pe care programele îl pot aborda. De exemplu, DLL-urile Windows XP și componentele de sistem care rulează în modul utilizator sunt mapate în spațiul de adrese al fiecărui proces, lăsând doar 2 sau 3 gigaocteți (în funcție de configurația sistemului) din spațiul de adrese disponibil, chiar dacă mașina are 4 gigaocteți de RAM. Această restricție nu este prezentă în versiunea pe 64 de biți a Windows.
  • Cartarea în memorie a fișierelor devine din ce în ce mai problematică pe sistemele pe 32 de biți, mai ales după introducerea soluțiilor rentabile pentru scrierea DVD- urilor. Fișierele de 4 GB sunt acum obișnuite și având în vedere dimensiunea lor, maparea memoriei lor pe mașinile de 32 de biți este complicată (doar o anumită porțiune trebuie stocată în memorie la un moment dat). Acest lucru duce la probleme de performanță, deoarece maparea în memorie rămâne una dintre cele mai eficiente metode pentru transferurile de disc-memorie atunci când sunt implementate corect de sistemul de operare.

Dezavantajul major al arhitecturilor pe 64 de biți în comparație cu arhitecturile pe 32 de biți este că aceleași date ocupă puțin mai mult spațiu în memorie (datorită pointerilor mai mari, a altor tipuri de date și a alinierilor ( compilatoarele inserează de obicei octeți neutilizați ). adrese de date la o putere de 2, adesea egală cu numărul de biți ai arhitecturii.) Aceasta crește cerințele de memorie ale programului și poate avea implicații pentru utilizarea eficientă a cache-ului (care are Parțial menținerea unui model de date pe 32 de biți este, în general, un mod rezonabil de eficient de gestionare a situației. De fapt, sistemul de operare z / OS foarte orientat spre performanță folosește această abordare și forțează codul executabil să locuiască în orice număr de spații de adrese de 32 de biți, în timp ce datele pot rezida opțional în 64 de biți regiuni.

Modele de date pe 64 de biți

Conversia aplicațiilor scrise în limbi pe 64 de biți la nivel înalt cu 32 are diferite grade de dificultate. O problemă recurentă este că autorul programului a presupus că un pointer (o variabilă care conține o adresă de memorie) are aceeași dimensiune ca o variabilă de alt tip și că, prin urmare, este posibilă mutarea valorilor între două tipuri fără a pierde informații . Această ipoteză este valabilă la unele 32 (și chiar la 16) mașini, dar nu reușește pe 64 de arhitecturi. Limbajul C și descendentul său C ++ facilitează în mod special acest tip de greșeală.

Pentru a evita această problemă, în C și C ++, operatorul sizeof() poate fi utilizat pentru a determina dimensiunea diferitelor tipuri de date, în cazul în care trebuie luate decizii cu privire la acestea în timpul execuției. În plus, fișierele limits.h (standard C99) și climits (standard C ++) oferă alte informații utile; sizeof () returnează doar dimensiunea în octeți, ceea ce uneori nu este suficientă, deoarece dimensiunea octetului nu este bine definită nici în C și C ++. Trebuie să fii atent și să folosești tipul ptrdiff_t (în fișierul antet <stddef.h> ) atunci când faci aritmetica pointerului ; prea mult cod folosește tipuri „int” și „lung” (în mod greșit).

Nici C, nici C ++ nu definesc lungimea de biți a unui pointer, int sau long.

În multe medii de programare pe sistemele pe 32 de biți, variabilele pointer, „int” și „long” au ambele 32 de biți lungime.

În multe medii de programare pe 64 de biți, variabilele „int” au încă 32 de biți lungime, dar „lungul” și indicatoarele se schimbă la 64. Acest lucru este descris ca având un model de date LP64 . O altă alternativă este modelul ILP64 în care tipul „int” se schimbă și pe 64 de biți. Cu toate acestea, în majoritatea cazurilor, modificările necesare pentru a migra codul pe 64 de biți sunt relativ simple și multe programe bine scrise pot fi recompilate fără modificări. O altă alternativă este modelul LLP64 care menține compatibilitatea cu codul pe 32 de biți, menținând tipurile „int” și „lung” la 32 de biți. Tipul „long long” („LL”) este de cel puțin 64 de biți pe toate platformele, inclusiv pe cele de 32 de biți.

Rețineți că modelul de programare este o alegere bazată pe compilator și că mai multe pot coexista pentru același sistem de operare. Cu toate acestea, modelul utilizat de API-urile sistemului de operare prevalează în general.

O altă considerație se referă la modelul de date utilizat pentru șoferi . Driverele formează cea mai mare parte a codului găsit în sistemele de operare moderne (deși este posibil ca mulți să nu ruleze în timp ce sistemul de operare rulează). Mulți șoferi folosesc puternic pointerele și, în unele cazuri, trebuie să încarce pointerele de o dimensiune precisă în registrele hardware de gestionare DMA . De exemplu, un driver pentru un dispozitiv PCI pe 32 de biți care necesită ca acesta din urmă să încarce date în memorie la o adresă dincolo de bariera de 4 gigaocteți nu a putut finaliza operațiunea, deoarece indicatorul este prea mare pentru a se potrivi în registrele dispozitivului. Problema este rezolvată prin faptul că sistemul de operare ia în considerare restricțiile dispozitivului atunci când generează cereri DMA.

Difuzie

Deja în 2006, procesoarele pe 64 de biți erau comune în servere și se răspândeau și în domeniul computerelor personale (anterior 32 de biți ), cu arhitecturile AMD64 , EM64T și PowerPC 970 . În anii următori, această difuzie a fost accelerată de nevoia din ce în ce mai presantă de a depăși limita de 4 gigaocteți de memorie centrală pe care o impune tehnologia pe 32 de biți.

Dincolo de 64 de biți

64 de biți pare suficient pentru majoritatea utilizărilor. Cu toate acestea, se poate menționa că IBM System / 370 a folosit numere în virgulă mobilă pe 128 de biți și că multe procesoare moderne le suportă și acum. Sistemul / 370 este de remarcat, totuși, deoarece a folosit și numere zecimale cu lungime variabilă până la maximum 16 octeți (adică 128 de biți).

OS / 400 folosește indicatori pe 128 de biți de ani de zile. Aplicațiile sunt concepute pentru a rula pe o mașină virtuală și apoi convertite la setul de instrucțiuni native odată instalat. Hardware-ul original era un sistem CISC pe 48 de biți similar cu System / 370 . Hardware-ul de astăzi este un PowerPC pe 64 de biți. Orice viitoare tranziție pe 128 de biți ar fi nedureroasă.

Cronologie

  • 1991: MIPS Technologies produce primul procesor pe 64 de biți, ca a treia revizuire a arhitecturii MIPS (tip RISC ), modelul R4000. Procesorul a fost disponibil în 1991 și utilizat în stațiile de lucru grafică SGI începând cu seria Crimson , utilizând versiunea pe 64 de biți a sistemului de operare IRIX .
  • 1992: Digital Equipment Corporation introduce arhitectura DEC Alpha născută din proiectul PRISM .
  • 1994: Intel își anunță planurile pentru arhitectura IA-64 pe 64 de biți (dezvoltată în comun cu HP ) pentru succesul procesorelor sale pe 32 de biți ( IA-32 ). Lansarea este programată pentru 1998-1999.
  • 1995: HAL Computer Systems (deținută de Fujitsu ) lansează stații de lucru pe 64 de biți bazate pe CPU, prima generație a SPARC64 proiectată independent de HAL. Ies sistemele AS / 400 pe 64 de biți ale IBM, care datorită arhitecturii lor specifice ( setul de instrucțiuni TIMI ) sunt capabile să convertească toate software-urile vechi pe 32 de biți în software nativ pe 64 de biți fără a fi nevoie să-l recompileze.
  • 1996: Sun și HP lansează procesoarele lor pe 64 de biți, UltraSPARC și PA-8000 . SunSolaris , IRIX și alte variante ale UNIX continuă să fie cele mai utilizate sisteme de operare pe 64 de biți.
  • 1997: IBM lansează procesoarele sale RS64 pe 64 de biți.
  • 1998: IBM își comercializează procesorul PowerPC pe 64 de biți.
  • 1999: Intel publică setul de instrucțiuni de arhitectură IA-64. Primele noutăți despre extensiile pe 64 de biți ( x86-64 ) pentru arhitectura IA-32 de la AMD .
  • 2000: IBM lansează primul său pe 64 de biți mainframe , de zSeries z900, iar noul z / OS sistemul de operare - culminând cu cea mai mare investiție în dezvoltarea CPU pe 64 de biți în istorie și instantaneu extermină sisteme compatibile. 31-bit produse de la concurenți, ca Fujitsu / Amdahl și Hitachi . Sistemele ZSeries cu Linux la bord urmează rapid.
  • 2001: Intel lansează în cele din urmă linia sa de procesoare pe 64 de biți, numită acum Itanium , care vizează piața serverelor high-end. Datorită întârzierilor continue în distribuția sa, Itanium nu respectă așteptările și se transformă într-un fiasco. Linux este primul sistem de operare care rulează pe procesor în momentul lansării sale.
  • 2002: Intel introduce Itanium 2 , succesorul lui Itanium.
  • 2003: AMD comercializează procesorul Opteron pe 64 de biți și gama de procesoare Athlon 64. Apple comercializează, de asemenea, procesoare PowerPC pe 64 de biți prin IBM și Motorola , împreună cu o actualizare a sistemului său de operare macOS . Mai multe distribuții Linux apar cu suport pentru arhitectură x86-64. Microsoft anunță dezvoltarea unei versiuni a sistemului său de operare Windows pentru cipuri AMD. Intel rămâne pe poziția sa de suport pentru Itanium ca singurul său procesor pe 64 de biți.
  • 2004: Intel, ca reacție la succesul arhitecturii AMD pe 64 de biți, admite dezvoltarea unei clone a extensiilor x86-64, pe care o numește EM64T . Versiunile actualizate ale familiilor Xeon și Pentium 4 care acceptă noile instrucțiuni vin pe piață.
  • 2005: În martie, Intel anunță că primul său procesor dual-core va fi pus în vânzare în al doilea trimestru al anului 2005, odată cu lansarea procesorului Pentium Extreme Edition 840 și a noilor cipuri Pentium D. Procesorii dual-core Itanium 2 vor urma al patrulea trimestru.
  • 2005: pe 18 aprilie, Beijing Longxin dezvăluie primul său procesor compatibil cu specificațiile x86-64, numit Longxin II . Cipul de aproximativ 2,5 centimetri pătrați conține 13,5 milioane de tranzistoare, cu o capacitate de vârf de două miliarde de operații pe secundă și, respectiv, un miliard de puncte plutitoare cu precizie simplă și dublă. Frecvența maximă este de 500 MHz și consumul variază între 3 și 5 wați.
  • 2005: pe 30 aprilie, Microsoft lansează Windows XP x64 Edition pentru procesoarele x86-64.
  • 2005: În mai, AMD lansează familia de procesoare dual-core Athlon 64 X2 pentru desktopuri. Procesoarele Athlon 64 X2 (Toledo) conțin două nuclee cu 1 MB de cache L2 per nucleu și sunt compuse din aproximativ 233,2 milioane de tranzistoare. Au o grosime de 199 mm².
  • 2005: În iulie, IBM anunță noul său procesor dual-core PowerPC 970MP pe 64 de biți (denumirea internă Antares).
  • 2013: pe 10 septembrie, Apple prezintă oficial primul telefon (iPhone 5S) cu arhitectură pe 64 de biți inclusă în cipul Apple A7

Arhitecturi pe 64 de biți

Arhitecturile pe 64 de biți includ (2005):

Elemente conexe

linkuri externe

Informatică Portal IT : accesați intrările Wikipedia care se ocupă cu IT