64 bit

64 biter , i informatikk , indikerer at i en gitt arkitektur er standardformatet til en enkel variabel ( heltall , peker , håndtak , etc.) 64 biter lang. Dette gjenspeiler generelt størrelsen på de interne CPU -registrene som brukes for den arkitekturen.

Begrepet "64 bit" kan brukes til å beskrive størrelsen på:

Beskrivelse

Arkitektoniske implikasjoner

Tall (også ment som informasjon) kan representeres på 64 biter i binær kode . Selv om en CPU kan være 64-bit internt, kan dens eksterne databuss eller adressebuss være av forskjellige størrelser, større eller mindre, og begrepet brukes ofte for å referere til størrelsen på disse bussene også. Det må derfor skilles mellom ekstern og intern bussparallellisme. En 8-bits ekstern buss begrenser ikke systemet til å operere med 1-byte data, det betyr bare at det ved hver hente-utførelsessyklus er i stand til å få tilgang til 8 biter med minne. På den annen side bestemmer parallelliteten til den interne bussen radikalt egenskapene til systemarkitekturen. Begrepet kan også brukes for å referere til størrelsen på op-koder i prosessorinstruksjonssettet eller andre data. I mangel av ytterligere avklaring har imidlertid en arkitektur beskrevet som "64 bits" vanligvis prosessorregistre 64 bits brede og håndterer data av denne størrelsen både internt og eksternt.

Registre, i en prosessor, er generelt delt inn i tre grupper: heltall, flytende komma og andre. I alle prosessorer for generell bruk er det bare heltallsregistre som er i stand til å holde pekere (dvs. adressen til noen data i minnet ). De andre registrene kan ikke inneholde pekere som skal brukes til å lese eller skrive minne, og kan derfor ikke brukes til å omgå begrensningene som pålegges av størrelsen på heltallsregistre.

Nesten alle prosessorer for generell bruk (med de viktige unntakene fra ARM-arkitekturen og de fleste 32-bits implementeringene av MIPS-arkitekturen ) har i dag integrert styring av flytende kommamatematikk, som kan eller ikke kan bruke registre. biter for å holde verdiene som skal behandles. X86 - arkitekturen , for eksempel, inneholder x87 - koprosessorens flyttallinstruksjoner , som bruker 8 80-bits registre i en stabelkonfigurasjon; senere versjoner og AMD -arkitekturen (som starter med Athlon XP ), inneholder også SSE -instruksjoner som bruker 16 128-bits registre. Derimot definerer 64-bits Alpha -familien 32 64-bits flyttallsregistre i tillegg til sine 32 64-bits heltallsregistre.

Minnebegrensninger

De fleste CPUer er utformet slik at et enkelt heltallsregister kan inneholde adressen til alle data i det virtuelle minneadresserommet . Derfor bestemmes det totale antallet adresser i virtuelt minne - totalen av data som datamaskinen kan holde i arbeidsområdet - av størrelsen på disse registerene. Fra 1960-tallet med IBMs System 360 , fortsatte inn i 1970-årene med (sammen med mange andre) minidatamaskinen DEC VAX , og til slutt på 1980-tallet med Intel 80386-prosessoren , utviklet det seg en de facto konsensus om at 32 bit var en god størrelse for logger. Et 32-bits register lar deg adressere 2 32 adresser, eller 4 gigabyte minne. På det tidspunktet disse arkitekturene ble designet, var 4 gigabyte minne så langt over mengden minne som normalt var installert at det ble ansett som tilstrekkelig. En annen viktig grunn er at 4 milliarder (omtrent) adresser er nok til å tilordne en enkelt referanse til mange fysisk tellbare objekter i applikasjoner som databaser .

Over tid og med den kontinuerlige nedgangen i minnekostnadene (se Moores lov ), nå på begynnelsen av nittitallet , begynte det å dukke opp maskiner med mengder RAM nær 4 gigabyte, og bruken av et virtuelt minneområde større enn 4 gigabyte begynte å bli nødvendig for å håndtere visse typer problemer. Som svar begynte en rekke selskaper å rulle ut nye brikkefamilier med 64-bits arkitektur, først for superdatamaskiner og avanserte maskiner ( arbeidsstasjoner og servere ). 64-bits teknologi har også gradvis kommet på vanlige PC-er, med Apples PowerMac (2003) og iMac (2004) som begge bruker 64-bits prosessorer (Apple kaller dem G5 ) , og AMD " AMD64 "-arkitekturen (som Intel gjenintroduserte med lite suksess under navnet " EM64T ") som sprer seg til avanserte PC -er . Ankomsten av 64-bits arkitekturer øker mengden adresserbart minne med opptil 2 64 byte, tilsvarende 16 exbibyte . En enorm mengde, akkurat som 4 gigabyte var for noen tiår siden.

32 versus 64 bit

Å flytte fra en 32-bits til en 64-bits arkitektur innebærer en dyp endring, ettersom de fleste operativsystemer må modifiseres kraftig for å dra nytte av den nye arkitekturen. Selv de andre programmene må først " porteres " for å kunne dra nytte av de nye funksjonene; Eldre programmer støttes generelt gjennom en maskinvarekompatibilitetsmodus (dvs. hvor prosessoren også støtter det gamle 32-bits instruksjonssettet), gjennom programvareemulering, eller til og med gjennom kjerneimplementeringen av en 32-bits prosessor hele den interne prosessorbrikken selv (som på Intels Itanium-prosessorer, som inkluderer en x86 -kjerne ). Et betydelig unntak er AS / 400 , hvis programvare kjører på en virtuell ISA (Instruction Set Architecture), kalt TIMI (Technology Independent Machine Interface) som oversettes, av et lavt-nivå programvarelag, til innebygd maskinkode før kjøring. Dette laget er alt som må skrives om for å bringe hele operativsystemet og alle programmer til en ny plattform, for eksempel da IBM migrerte linjen fra de gamle 32/48-bits "IMPI" -prosessorene til 64-biters PowerPC -er (IMPI gjorde har ikke noe med 32-biters PowerPC å gjøre , så det var en mer utfordrende overgang enn å bytte fra et 32-bits instruksjonssett til 64-biters versjonen av den). Et annet bemerkelsesverdig unntak er IBMs z / Architecture som jevnt kjører applikasjoner med forskjellige adresseringstyper (24, 32 og 64 bit) samtidig.

Mens 64-bits arkitekturer utvilsomt gjør det lettere å jobbe med enorme mengder data som digital video , vitenskapelig prosessering og store databaser , har det vært mye diskusjon om hvor mye mer kompatible de eller deres 32-bits moduser er. raskt , i andre typer jobber, sammenlignet med lignende 32-bits systemer.

Teoretisk sett kan noen programmer være raskere i 32-bits modus. På visse arkitekturer tar 64-bits instruksjoner mer plass enn 32-biters, så det er mulig at visse 32-biters programmer kan gå inn i den svært raske CPU - cachen der 64-biters ikke kan. Med andre ord, å bruke 64 biter for å utføre operasjoner som kan administreres ved 32, innebærer en unødvendig sløsing med ressurser (sentralminne, hurtigbuffer, etc.). Imidlertid, i applikasjoner som vitenskap, bruker de behandlede dataene ofte 64-bits blokker naturlig, og vil derfor være raskere på en 64-bits arkitektur da CPUen er designet for å jobbe direkte med denne størrelsen i stedet for å begrense programmer. for å utføre flere trinn for å oppnå samme resultat. Disse vurderingene kompliseres også av det faktum at designere av instruksjonssettet under definisjonen av de nye arkitekturene benyttet anledningen til å gjøre endringer som fyller hull i den gamle, og legger til nye funksjoner som tar sikte på å forbedre ytelsen (som f.eks. , for eksempel tilleggsregistrene i AMD64-arkitekturen).

Fordeler og ulemper

En vanlig misforståelse er at 64-bits arkitektur ikke er bedre enn 32-bits arkitektur med mindre du har mer enn 4 gigabyte minne. Dette er ikke helt sant:

Den største ulempen med 64-bits over 32-bits arkitekturer er at de samme dataene tar opp litt mer minneplass (på grunn av større pekere, andre datatyper og justeringer ( kompilatorer setter vanligvis inn ubrukte byte svært ytelsesorienterte z/OS -operativsystemet bruker denne tilnærmingen og tvinger den kjørbare koden til å ligge i et hvilket som helst antall 32-bits adresserom mens dataene eventuelt kan ligge i 64-bits områder.

64-biters datamodeller

Konvertering av applikasjoner skrevet på høyt nivå 32 til 64-bits språk presenterer varierende vanskelighetsgrader. Et tilbakevendende problem er at forfatteren av programmet har antatt at en peker (en variabel som inneholder en minneadresse) har samme størrelse som en variabel av en annen type og at det derfor er mulig å flytte verdier mellom to typer uten å miste informasjon. Denne antagelsen gjelder på rundt 32 (og noen 16) maskiner, men feiler på 64 arkitekturer. C-språket og dets C++- etterkommer gjør det spesielt enkelt å gjøre denne typen feil.

For å unngå dette problemet, i C og C++, kan operatøren sizeof()brukes til å bestemme størrelsen på ulike datatyper, i tilfelle det må tas avgjørelser om disse under utførelse. I tillegg gir filene limits.h (standard C99) og climits (standard C ++) ytterligere nyttig informasjon; sizeof () returnerer bare størrelsen i byte, noe som noen ganger ikke er nok, fordi bytestørrelsen heller ikke er godt definert i C og C++. Du må være forsiktig og bruke typen ptrdiff_t(i overskriftsfilen <stddef.h>) når du utfører pekeraritmetikk ; for mye kode bruker "int" og "long" typer i stedet (feilaktig).

Verken C eller C++ definerer bitlengden til en peker, int eller long.

I mange programmeringsmiljøer på 32-bits systemer er pekervariablene "int" og "long" begge 32 biter lange.

I mange 64-bits programmeringsmiljøer er "int"-variablene fortsatt 32 biter lange, men "lange" og pekere endres til 64. Dette beskrives som å ha en LP64 - datamodell . Et annet alternativ er ILP64- modellen hvor "int"-typen også endres til 64 bits. Men i de fleste tilfeller er endringene som kreves for å migrere kode til 64-bit relativt enkle, og mange velskrevne programmer kan ganske enkelt rekompileres uten endringer. Et annet alternativ er LLP64- modellen som opprettholder kompatibilitet med 32-bits kode ved å holde "int" og "long" på 32-bit. "Lang lang" ("LL") typen er minst 64-bit på alle plattformer inkludert 32-bit.

Merk at programmeringsmodellen er et kompilatorbasert valg, og mer enn én kan eksistere side om side for samme operativsystem. Imidlertid er modellen som brukes av operativsystemets APIer generelt rådende.

En annen vurdering gjelder datamodellen som brukes for sjåførene . Drivere utgjør hoveddelen av koden som finnes i moderne operativsystemer (selv om mange kanskje ikke kjører mens operativsystemet kjører). Mange drivere bruker pekere tungt og må i noen tilfeller laste pekere av en presis størrelse inn i DMA -administrasjonsmaskinvareregistrene . For eksempel, en driver for en 32-bits PCI -enhet som krever at sistnevnte laster data inn i minnet på en adresse utenfor 4 gigabyte-barrieren, kunne ikke fullføre operasjonen fordi pekeren er for stor til å passe inn i enhetens register. Problemet løses ved å la operativsystemet ta hensyn til enhetsbegrensninger når det genereres DMA-forespørsler.

Formidling

Allerede i 2006 var 64-bits CPUer vanlige på servere og spredte seg også innen personlige datamaskiner (tidligere 32-bit ), med AMD64 , EM64T og PowerPC 970-arkitekturene . I de påfølgende årene ble denne spredningen akselerert av det stadig mer presserende behovet for å overvinne grensen på 4 gigabyte sentralt minne som 32-bits teknologi pålegger.

Utover 64-bit

64-bit ser ut til å være tilstrekkelig for de fleste bruksområder. Det kan imidlertid nevnes at IBM System / 370 brukte 128-bits flyttall , og at mange moderne prosessorer nå støtter dem også. System / 370 er imidlertid bemerkelsesverdig, siden den også brukte desimaltall med variabel lengde opp til maksimalt 16 byte (dvs. 128 biter).

OS / 400 har brukt 128-bits pekere i årevis. Applikasjoner er designet for å kjøre på en virtuell maskin , og deretter konverteres til det opprinnelige instruksjonssettet når de er installert. Den originale maskinvaren var et 48-biters CISC-system som ligner på System / 370 . Dagens maskinvare er en 64-bits PowerPC . Enhver fremtidig 128-bits overgang vil være smertefri.

Historie

64-bits arkitekturer

64 - bits arkitekturer inkluderer (2005):

Relaterte elementer

Eksterne lenker