Innen databehandling er IA-64 (Intel Architecture-64) en 64-bits arkitektur utviklet under et samarbeid mellom Intel og Hewlett-Packard og implementert av prosessorer som Itanium og Itanium 2 . Itaniums mål var å introdusere en "post- RISC " -arkitektur ved å bruke EPIC . For denne 64-bits prosessoren har Microsoft og Intel skrevet operativsystemet Windows XP 64-bit Edition .
I en typisk "out-of-order" design ( ofte kjent som out-of-order ), undersøker en veldig kompleks dekoder hver instruksjon som sendes til CPU -en når den krysser rørledningen og sjekker hvilke som kan kjøres parallelt i utførelsen enheter - f.eks. , et par instruksjoner som A = B + Cog D = F + Gpåvirker ikke hverandre, og kan derfor utføres parallelt i to forskjellige utførelsesenheter. Evnen til å gjenkjenne parallellitet på instruksjonsnivå i instruksjonsflyt er avgjørende for god ytelse i en moderne CPU.
Å forutsi når kode ikke kan deles på denne måten er en svært kompleks oppgave. I mange tilfeller avhenger utførelsen av en instruksjon av logiske forhold avhengig av andre instruksjoner. Tenk for eksempel på en liten modifikasjon av forrige eksempel: A = B + C; IF A==5 THEN D = F + G(som indikerer å legge til B og C og sette inn resultatet i A, og hvis A er lik fem, så sett inn i D resultatet av summen mellom F og G). I dette tilfellet er resultatet av den andre beregningen fortsatt uavhengig av den første, men den første operasjonen må først utføres for å vite om den andre må utføres eller ikke.
I disse tilfellene "gjetter" CPU-en vanligvis om den logiske betingelsen er sann eller usann. I omtrent 90 % av tilfellene blir koden etter a IFutført, noe som antyder at den andre halvdelen av kommandoene i vårt eksempel kan utføres av en annen utførelsesenhet. Men å forutsi feil resultat for den logiske tilstanden kan føre til betydelige ytelsesfall, på grunn av det faktum at verdien beregnet av den andre enheten er feil og CPU-en må vente på å kunne beregne resultatet av den riktige instruksjonen. Mye av ytelsesøkningen på nåværende CPU-er skyldes forbedret prediksjonslogikk, men forbedringene har bremset ned i det siste. Forutsigelsen av kodegrener (kalt grenprediksjon ) i gjeldende CPUer er korrekt omtrent 98 % av tiden.
IA-64-arkitekturen på den annen side er avhengig av kompilatoren for denne oppgaven. Selv før programmet kjøres av CPU-en, undersøker kompilatoren koden og tar de samme typene avgjørelser som ellers ville forekomme når den kjøres på selve CPU-en. Når den har bestemt hvilke instruksjoner som kan utføres parallelt effektivt, slår den dem sammen til en større instruksjon og skriver dem i denne formen i programmet - derav navnet very long instruction word (VLIW).
Å tilordne denne oppgaven til kompilatoren i stedet for CPU har flere fordeler. For det første kan kompilatoren ta lang tid å gå gjennom koden, en sjanse prosessoren ikke har fordi den må utføre instruksjoner så raskt som mulig. Så kompilatorbeslutninger kan være betydelig mer nøyaktige enn de som gjøres av maskinvare. For det andre er kretsene for grenprediksjon ganske komplekse, og nedlasting av prediksjonen til kompilatoren reduserer kompleksiteten til prosessoren: den trenger ikke lenger å undersøke noe, den må bare bryte instruksjonene og få dem til å kjøre parallelt med enhetene. For det tredje, å kjøre prediksjonen i kompilatoren har en engangskostnad , i motsetning til kostnaden på CPU, som må kjøres hver gang programmet brukes.
Ulempen er at oppførselen til et program under kjøring ikke alltid er tydelig i koden som brukes til å lage det, og kan variere betydelig avhengig av dataene det faktisk behandler. En CPUs utkjøringslogikk kan ta avgjørelser basert på data som faktisk behandles av programmet, og som kompilatoren bare kan "gjette". Dette betyr at kompilatorprediksjoner kan være feil oftere enn en logisk krets med sammenlignbar (eller enda enklere) kompleksitet plassert på CPU-en kan. VLIW-designet er derfor avhengig av kompilatorytelse, og betaler for forenklingen av prosessoren med den økte kompleksiteten til programvaren.
IA-64-arkitekturen inkluderer et stort sett med registre: 128 registre ved 82-bits flytende komma og 64-biters for heltall. I tillegg til dette store antallet, legger IA-64 til en registervindusmekanisme kontrollert av Register Stack Engine . Dette systemet kombinert med prediksjon er veldig effektivt for automatisk å utføre "avrulling av sykluser" (i programmeringsjargong "rulle ut en sløyfe" - å rulle ut en sløyfe - betyr å eksplisitt gjøre en syklus med instruksjoner utført flere ganger, og liste dem alle i sin helhet, som typisk fører til forbedret ytelse).
IA-64-arkitekturen gir instruksjoner for operasjoner på multimediedata og for flytende kommaberegninger.
Mens en typisk VLIW-arkitektur tildeler underinstruksjoner fra hver "stor instruksjon" til en bestemt spesifikk utførelsesenhet, støtter Itanium forskjellige moduser for instruksjonsforening som gir en bedre balanse mellom serie- og parallellutførelsesmoduser.
Så snart den er slått på, mangler en Itanium-prosessor noen funksjoner. Et " Prosessor Abstraksjonslag " ( PAL) er innebygd i BIOS og ved oppstart lastes det inn i CPU for å gi et lavnivågrensesnitt som abstraherer visse instruksjoner og gir en mekanisme for å oppdatere prosessoren via en BIOS-oppdatering.
Under BIOS-initialisering lastes et annet kodelag, System Abstraction Layer (SAL) for å gi standard APIer som trengs for plattformimplementeringsavhengige funksjoner.
Over PAL- og SAL-grensesnittene er " Extensible Firmware Interface " (EFI), grensesnittet for utvidbar fastvare . EFI er ikke en del av IA-64-arkitekturen, men etter konvensjon er det nødvendig for alle IA-64-systemer. Det er et enkelt API for å få tilgang til de logiske aspektene ved systemet (lagring, video, tastatur, etc.) kombinert med et lett kjøringssystem (ligner på DOS ) som tillater kjøring av systemadministrasjonsfunksjoner, som oppdatering av BIOS, konfigurere lagringsenheter, konfigurere en oppstartslaster .
Når operativsystemet er startet opp, forblir noen funksjoner i PAL, SAL og eFI i minnet og kan brukes av operativsystemet til å utføre lavnivå- og maskinvareavhengige operasjoner.
For å støtte IA-32- arkitekturen kan Itanium gå inn i en 32-bits modus med spesielle instruksjoner. IA-32-instruksjonene er implementert i funksjonsenhetene til Itanium. Men siden Itanium er designet primært for hastighet på EPIC -instruksjoner , og på grunn av manglende evne til å kjøre kode i ut-av-ordre- modus , kjører IA-32-kode med svært store ytelsesstraff sammenlignet med AI-modus. -64 eller Pentium-prosessorer . For eksempel setter ikke Itanium-utførelsesenheter opp flere feiljusterte minnetilganger. Det finnes også gratis IA-32-emuleringsprogramvare tilgjengelig for Microsoft Windows- og Linux- operativsystemer som yter omtrent 50 % høyere enn prosessoremuleringsmodusen. Emulatoren for Windows er tilgjengelig fra Microsoft, emulatoren for Linux er tilgjengelig fra noen Linux-forhandlere som Novell .
Gitt den overlegne ytelsen til programvareemulatorer, og selv om maskinvaren som kreves for å emulere IA-32 er ansvarlig for mindre enn 1 % av Itanium 2s transistorer , har Intel fjernet IA-32-emulering fra sjette generasjon Itanium 2-brikker. Kodenavnet Montecito [1] (vi er for tiden på den niende Tukwila ).
Mens andre 64-bits arkitekturer har eksistert i lang tid, har de fleste ( Alfa , PA-RISC ) forsvunnet fra markedet. Itaniums konkurrenter i kampen om server- og arbeidsstasjonsmarkedet ser ut til å være AMD med sin AMD64 -arkitektur , IBM med POWER -arkitekturen og Sun Microsystems med UltraSparc . Selv om Apple kunne ha konkurrert med Intel med sin PowerPC - baserte Xserve -produktlinje fra IBM, virker slike utsikter umulige etter Apples kunngjøring av overgangen til Intels IA-32-arkitektur.
Som svar på bransjens positive reaksjon på AMD64, støtter neste versjon av Intel Xeon ( Nocona ) EM64T -utvidelser , som stort sett er kompatible med AMD64s instruksjonssett.