Intel iAPX 432
Allmän information | |
---|---|
Lanserades | slutet av 1981 |
Avvecklad | ca 1985 |
Vanliga tillverkare |
|
Prestanda | |
Max. CPU klockfrekvens | 5 MHz till 8 MHz |
iAPX 432 ( Intel Advanced Performance Architecture ) är en avvecklad datorarkitektur som introducerades 1981. Det var Intels första 32-bitars processordesign . Arkitekturens huvudprocessor, den allmänna dataprocessorn , är implementerad som en uppsättning av två separata integrerade kretsar, på grund av tekniska begränsningar vid den tidpunkten. Även om vissa tidiga 8086-, 80186- och 80286-baserade system och manualer också använde iAPX- prefixet av marknadsföringsskäl, är iAPX 432- och 8086-processorlinjerna helt separata konstruktioner med helt olika instruktionsuppsättningar.
Projektet startade 1975 som 8800 (efter 8008 och 8080 ) och var tänkt att vara Intels huvuddesign för 1980-talet. Till skillnad från 8086 , som designades året därpå som en efterföljare till 8080, var iAPX 432 ett radikalt avsteg från Intels tidigare konstruktioner avsedda för en annan marknadsnisch, och helt orelaterade till produktlinjerna 8080 eller x86 .
iAPX 432-projektet anses vara ett kommersiellt misslyckande för Intel och avbröts 1986.
Beskrivning
iAPX 432 kallades en "micromainframe", designad för att programmeras helt och hållet på högnivåspråk. Instruktionsuppsättningsarkitekturen var också helt ny och en betydande avvikelse från Intels tidigare 8008- och 8080- processorer eftersom iAPX 432 - programmeringsmodellen är en stackmaskin utan synliga allmänna register . Den stöder objektorienterad programmering , sophämtning och multitasking samt mer konventionell minneshantering direkt i hårdvara och mikrokod . Direktstöd för olika datastrukturer är också tänkt att möjliggöra implementering av moderna operativsystem med mycket mindre programkod än för vanliga processorer. Intel iMAX 432 är ett utgått operativsystem för 432, skrivet helt i Ada , och Ada var också det avsedda primära språket för applikationsprogrammering. I vissa aspekter kan det ses som en datorarkitektur på hög nivå .
Dessa egenskaper och funktioner resulterade i en hårdvaru- och mikrokoddesign som var mer komplex än de flesta processorer av eran, särskilt mikroprocessorer. Dock är interna och externa bussar (för det mesta) inte bredare än 16-bitars , och precis som i andra 32-bitars mikroprocessorer av eran (som 68000 eller 32016 ), implementeras 32-bitars aritmetiska instruktioner av en 16 -bit ALU, via slumpmässig logik och mikrokod eller andra typer av sekventiell logik . Det utökade adressutrymmet i iAPX 432 över 8080 var också begränsat av det faktum att linjär adressering av data fortfarande bara kunde använda 16-bitars offsets, något liknande Intels första 8086 -baserade design, inklusive den samtida 80286 (det nya 32-bitars segmentet) offset av 80386- arkitekturen beskrevs offentligt i detalj 1984).
Med hjälp av sin tids halvledarteknik kunde inte Intels ingenjörer översätta designen till en mycket effektiv första implementering. Tillsammans med bristen på optimering i en för tidig Ada- kompilator, bidrog detta till ganska långsamma men dyra datorsystem, som utförde typiska riktmärken på ungefär 1/4 hastigheten för det nya 80286 -chippet vid samma klockfrekvens (i början av 1982). Denna initiala prestandagap till den ganska lågprofilerade och lågprissatta 8086- linjen var förmodligen huvudorsaken till att Intels plan att ersätta den senare (senare känd som x86 ) med iAPX 432 misslyckades. Även om ingenjörer såg sätt att förbättra en nästa generations design, hade iAPX 432- kapacitetsarkitekturen nu börjat betraktas mer som en implementeringsoverhead snarare än som det förenklingsstöd den var tänkt att vara.
Ursprungligen designad för klockfrekvenser på upp till 10 MHz, såldes de faktiska enheterna specificerade för maximala klockhastigheter på 4 MHz, 5 MHz, 7 MHz och 8 MHz med en toppprestanda på 2 miljoner instruktioner per sekund vid 8 MHz.
Historia
Utveckling
Intels 432-projekt startade 1976, ett år efter att 8-bitars Intel 8080 färdigställdes och ett år innan deras 16-bitars 8086 -projekt började. 432-projektet hette ursprungligen 8800 , som deras nästa steg bortom de befintliga Intel 8008- och 8080 -mikroprocessorerna. Detta blev ett väldigt stort steg. Instruktionsuppsättningarna för dessa 8-bitars processorer var inte särskilt väl anpassade för typiska Algol -liknande kompilerade språk . Det stora problemet var dock deras små inhemska adresseringsintervall, bara 16 KB för 8008 och 64 KB för 8080, alldeles för litet för många komplexa mjukvarusystem utan att använda någon form av bankväxling, minnessegmentering eller liknande mekanism (som var inbyggd i 8086, några år senare). Intel siktade nu på att bygga ett sofistikerat komplett system i några få LSI-chips, som funktionellt sett var lika med eller bättre än de bästa 32-bitars minidatorer och stordatorer som kräver hela skåp med äldre chips. Detta system skulle stödja multiprocessorer, modulär expansion, feltolerans, avancerade operativsystem, avancerade programmeringsspråk, mycket stora applikationer, ultratillförlitlighet och ultrasäkerhet. Dess arkitektur skulle möta behoven hos Intels kunder under ett decennium.
iAPX 432-utvecklingsteamet leddes av Bill Lattin, med Justin Rattner som ledande ingenjör (även om en källa uppger att Fred Pollack var ledande ingenjör). (Rattner skulle senare bli CTO för Intel.) Till en början arbetade teamet från Santa Clara, men i mars 1977 flyttade Lattin och hans team på 17 ingenjörer till Intels nya plats i Portland. Pollack specialiserade sig senare på superskalaritet och blev den ledande arkitekten för i686-chippet Intel Pentium Pro .
Det stod snart klart att det skulle ta flera år och många ingenjörer att designa allt detta. Och det skulle på samma sätt ta flera år av ytterligare framsteg i Moores lag innan förbättrad chiptillverkning kunde passa in allt detta i några täta chips. Samtidigt behövde Intel akut en enklare interimsprodukt för att möta den omedelbara konkurrensen från Motorola , Zilog och National Semiconductor . Så Intel påbörjade ett hastigt projekt för att designa 8086 som en inkrementell utveckling med låg risk från 8080, med hjälp av ett separat designteam. Massmarknaden 8086 levererades 1978.
8086 designades för att vara bakåtkompatibel med 8080 i den meningen att 8080 assemblerspråk kunde mappas till 8086-arkitekturen med en speciell assembler . Befintlig 8080- sammansättningskällkod (om än ingen körbar kod ) gjordes därmed uppåtkompatibel med den nya 8086 till viss del. Däremot hade 432 inga programvarukompatibilitet eller migreringskrav. Arkitekterna hade total frihet att göra en ny design från grunden, med de tekniker som de anade skulle vara bäst för storskaliga system och mjukvara. De tillämpade fashionabla datavetenskapliga koncept från universitet, särskilt kapacitetsmaskiner , objektorienterad programmering, CISC-maskiner på hög nivå, Ada och tätt kodade instruktioner. Denna ambitiösa blandning av nya funktioner gjorde chippet större och mer komplext. Chipets komplexitet begränsade klockhastigheten och förlängde designschemat.
Kärnan i designen – huvudprocessorn – kallades General Data Processor ( GDP ) och byggdes som två integrerade kretsar : en (43201) för att hämta och avkoda instruktioner, den andra (43202) för att exekvera dem. De flesta system skulle också inkludera 43203 Interface Processor ( IP ) som fungerade som en kanalkontroller för I/O , och en Attached Processor ( AP ), en konventionell Intel 8086 som gav "processorkraft i I/O-undersystemet".
Dessa var några av de största [ förtydligande behövs ] designen av eran. BNP med två chip hade ett kombinerat antal på cirka 97 000 transistorer medan IP-adressen för en enda chip hade cirka 49 000. Som jämförelse Motorola 68000 (introducerad 1979) cirka 40 000 transistorer. [ citat behövs ]
1983 släppte Intel ytterligare två integrerade kretsar för iAPX 432 Interconnect Architecture: 43204 Bus Interface Unit ( BIU ) och 43205 Memory Control Unit ( MCU ). Dessa chips möjliggjorde nästan limlösa multiprocessorsystem med upp till 63 noder.
Projektets misslyckanden
Några av de innovativa funktionerna i iAPX 432 var skadliga för god prestanda. I många fall hade iAPX 432 en betydligt långsammare instruktionsgenomströmning än dåtidens konventionella mikroprocessorer, som National Semiconductor 32016 , Motorola 68010 och Intel 80286 . Ett problem var att implementeringen av två chip av BNP begränsade den till hastigheten på moderkortets elektriska ledningar. Ett större problem var att kapacitetsarkitekturen behövde stora associativa cacher för att köras effektivt, men chipsen hade inget utrymme kvar för det. Instruktionsuppsättningen använde också bitjusterade instruktioner med variabel längd istället för de vanliga halvfixerade byte- eller ordjusterade formaten som används i de flesta datordesigner. Instruktionsavkodning var därför mer komplex än i andra konstruktioner. Även om detta inte hämmade prestandan i sig använde den ytterligare transistorer (främst för en stor växelväxlare ) i en design som redan saknade utrymme och transistorer för cacher, bredare bussar och andra prestandaorienterade funktioner. Dessutom var BIU designad för att stödja feltoleranta system, och på så sätt hölls upp till 40 % av busstiden uppe i väntelägen .
Ett annat stort problem var dess omogna och ojusterade Ada- kompilator . Den använde dyrbara objektorienterade instruktioner i varje fall, istället för de snabbare skalära instruktionerna där det skulle ha varit vettigt att göra det. Till exempel inkluderade iAPX 432 en mycket dyr intermodulproceduranropsinstruktion, som kompilatorn använde för alla samtal, trots förekomsten av mycket snabbare gren- och länkinstruktioner. Ett annat mycket långsamt anrop var enter_environment, som satte upp minnesskyddet. Kompilatorn körde detta för varje enskild variabel i systemet, även när variabler användes i en befintlig miljö och inte behövde kontrolleras. För att göra saken värre skickades data som skickades till och från procedurer alltid genom värderetur snarare än genom referens. När man körde Dhrystone benchmark tog parameteröverföringen tio gånger längre tid än alla andra beräkningar tillsammans.
Enligt New York Times "körde i432 5 till 10 gånger långsammare än sin konkurrent, Motorola 68000".
Impact och liknande konstruktioner
iAPX 432 var ett av de första systemen som implementerade den nya IEEE-754 -standarden för flytpunktsarithmetik.
Ett resultat av misslyckandet med 432:an var att mikroprocessordesigners drog slutsatsen att objektstöd i chippet leder till en komplex design som alltid kommer att gå långsamt, och 432:an citerades ofta som ett motexempel av förespråkare för RISC- designer . Vissa menar dock att OO-stödet inte var det primära problemet med 432:an, och att implementeringsbristerna (särskilt i kompilatorn) som nämns ovan skulle ha gjort all CPU-design långsam. Sedan iAPX 432 har det bara gjorts ett annat försök till en liknande design, Rekursiv -processorn, även om INMOS-transputerns processstöd var liknande — och mycket snabbt. [ citat behövs ]
Intel hade spenderat mycket tid, pengar och mindshare på 432:an, hade ett skickligt team ägnat åt den och var ovillig att överge den helt efter dess misslyckande på marknaden. En ny arkitekt – Glenford Myers – togs in för att producera en helt ny arkitektur och implementering för kärnprocessorn, som skulle byggas i ett gemensamt Intel / Siemens -projekt (senare BiiN ), vilket resulterade i i960 -seriens processorer. i960 RISC-undergruppen blev populär under en tid på marknaden för inbäddade processorer, men avancerade 960MC och 960MX med taggat minne marknadsfördes endast för militära applikationer.
Enligt New York Times var Intels samarbete med HP om Merced-processorn (senare känd som Itanium) företagets comebackförsök för den mycket avancerade marknaden.
Arkitektur
iAPX 432-instruktionerna har variabel längd, mellan 6 och 321 bitar. Ovanligtvis är de inte byte-justerade, det vill säga de kan innehålla udda antal bitar och direkt följa varandra utan hänsyn till bytegränser.
Objektorienterat minne och kapacitet
iAPX 432 har hårdvaru- och mikrokodstöd för objektorienterad programmering och kapacitetsbaserad adressering . Systemet använder segmenterat minne , med upp till 2 24 segment på upp till 64 KB vardera, vilket ger ett totalt virtuellt adressutrymme på 2 40 byte. Det fysiska adressutrymmet är 2 24 byte (16 MB ).
Program kan inte referera till data eller instruktioner per adress; istället måste de ange ett segment och en offset inom segmentet. Segment refereras av åtkomstdeskriptorer (ADs) , som tillhandahåller ett index i systemobjekttabellen och en uppsättning rättigheter ( kapaciteter ) som styr åtkomst till det segmentet. Segment kan vara "åtkomstsegment", som bara kan innehålla åtkomstdeskriptorer, eller "datasegment" som inte kan innehålla AD. Hårdvaran och mikrokoden framtvingar strikt distinktionen mellan data och åtkomstsegment och tillåter inte programvara att behandla data som åtkomstdeskriptorer, eller vice versa.
Systemdefinierade objekt består av antingen ett enskilt åtkomstsegment eller ett åtkomstsegment och ett datasegment. Systemdefinierade segment innehåller data eller åtkomstbeskrivningar för systemdefinierade data vid angivna förskjutningar, även om operativsystemet eller användarprogramvaran kan utöka dessa med ytterligare data. Varje systemobjekt har ett typfält som kontrolleras med mikrokod, så att ett portobjekt inte kan användas där ett bärarobjekt behövs. Användarprogram kan definiera nya objekttyper som kommer att få full nytta av maskinvarutypkontrollen, genom användning av typkontrollobjekt (TCOs) .
I version 1 av iAPX 432-arkitekturen bestod ett systemdefinierat objekt typiskt av ett åtkomstsegment och valfritt (beroende på objekttyp) ett datasegment specificerat av en åtkomstdeskriptor med en fast förskjutning inom åtkomstsegmentet.
I version 3 av arkitekturen, för att förbättra prestanda, kombinerades åtkomstsegment och datasegment till enskilda segment på upp till 128 kB, uppdelade i en åtkomstdel och en datadel på 0–64 KB vardera. Detta minskade antalet objekttabellsökningar dramatiskt och fördubblade det maximala virtuella adressutrymmet.
iAPX432 känner igen fjorton typer av fördefinierade systemobjekt :
- instruktionsobjektet innehåller körbara instruktioner
- domänobjekt representerar en programmodul och innehåller referenser till subrutiner och data
- kontextobjekt representerar sammanhanget för en process som körs
- typdefinitionsobjekt representerar en mjukvarudefinierad objekttyp
- typkontrollobjekt representerar typspecifik behörighet
- objekttabell identifierar systemets samling av aktiva objektdeskriptorer
- lagringsresursobjekt representerar en gratis lagringspool
- fysiskt lagringsobjekt identifierar lediga lagringsblock i minnet
- lagringsanspråksobjekt begränsar lagring som kan tilldelas av alla associerade lagringsresursobjekt
- processobjekt identifierar en pågående process
- portobjekt representerar en port och meddelandekö för kommunikation mellan processer
- transportör Transportörer bär meddelanden till och från hamnar
- processor innehåller tillståndsinformation för en processor i systemet
- processorkommunikationsobjekt används för interprocessorkommunikation
Skräp samling
Programvara som körs på 432:an behöver inte explicit deallokera objekt som inte längre behövs. Istället implementerar mikrokoden en del av markeringsdelen av Edsger Dijkstras parallella sophämtningsalgoritm (en mark-and-sweep- samlare). Posterna i systemobjekttabellen innehåller de bitar som används för att markera varje objekt som vitt, svart eller grått efter behov av samlaren. Operativsystemet iMAX 432 inkluderar mjukvarudelen av sopsamlaren.
Instruktionsformat
Körbara instruktioner finns i ett system "instruktionsobjekt". På grund av att instruktioner är bitjusterade, tillåter en 16-bitars bitförskjutning in i instruktionsobjektet att objektet innehåller upp till 65 536 bitar (8 192 byte) instruktioner.
Instruktioner består av en operator , bestående av en klass och en opcode , och noll till tre operandreferenser . "Fälten är organiserade för att presentera information till processorn i den sekvens som krävs för avkodning". Mer frekvent använda operatorer kodas med färre bitar. Instruktionen börjar med 4- eller 6-bitars klassfältet som indikerar antalet operander, kallad ordning , och längden på varje operand. Detta följs valfritt av ett 0 till 4 bitars formatfält som beskriver operanderna (om det inte finns några operander finns inte formatet). Sedan kommer noll till tre operander, som beskrivs av formatet. Instruktionen avslutas av 0 till 5 bitars opkod, om någon (vissa klasser innehåller bara en instruktion och har därför ingen opkod). "Formatfältet tillåter att GDP visas för programmeraren som en noll-, en-, två- eller treadressarkitektur." Formatfältet indikerar att en operand är en datareferens, eller det översta eller nästa-till-översta elementet i operandstacken.
Se även
- iAPX , för iAPX-namnet
Anteckningar
externa länkar
- IAPX 432-manualer på Bitsavers.org
- Datorhistoriska museet
- Intel iAPX432 Micromainframe innehåller en lista över all Intel-dokumentation som är associerad med iAPX 432, en lista över maskinvaruartikelnummer och en lista med mer än 30 papper.