IBM 801

Den här artikeln handlar om 1970-talets IBM CPU. För dokumentbehandlaren som släpptes 1934, se IBM dokumentbehandlare § IBM 801 .

801 var en experimentell central processing unit (CPU) design som utvecklades av IBM under 1970-talet . Det anses vara den första moderna RISC- designen, som förlitar sig på processorregister för alla beräkningar och eliminerar de många olika adresseringslägena som finns i CISC -designer. Ursprungligen utvecklad som processor för en telefonväxel , användes den senare som bas för en minidator och ett antal produkter för deras stordatorlinje . Den ursprungliga designen var en 24-bitars processor; som snart ersattes av 32-bitars implementeringar av samma koncept och den ursprungliga 24-bitars 801 användes först i början av 1980-talet.

801:an var extremt inflytelserik på datormarknaden. Beväpnad med enorma mängder prestandadata kunde IBM visa att den enkla designen lätt kunde överträffa även de mest kraftfulla klassiska CPU-designerna, samtidigt som den producerade maskinkod som bara var marginellt större än de kraftigt optimerade CISC- instruktionerna . Att tillämpa samma teknik även på befintliga processorer som System/370 fördubblade i allmänhet även dessa systems prestanda. Detta visade värdet av RISC-konceptet, och alla IBMs framtida system baserades på de principer som utvecklades under 801-projektet.

För sitt arbete på 801:an belönades John Cocke med flera utmärkelser och medaljer, inklusive Turing Award 1987, National Medal of Technology 1991 och National Medal of Science 1994.

Historia

Originalkoncept

1974 började IBM undersöka möjligheten att konstruera en telefonväxel för att hantera en miljon samtal i timmen, eller cirka 300 samtal per sekund. De beräknade att varje samtal skulle kräva 20 000 instruktioner att slutföra, och när man lade till timingoverhead och andra överväganden, krävde en sådan maskin prestanda på cirka 12 MIPS. Detta skulle kräva ett betydande framsteg i prestanda; deras nuvarande top-of-the-line maskin, IBM System/370 Model 168 från slutet av 1972, erbjöd cirka 3 MIPS.

Gruppen som arbetar med detta projekt vid Thomas J. Watson Research Center , inklusive John Cocke , designade en processor för detta ändamål. För att uppnå den krävda prestandan övervägde de vilken typ av operationer en sådan maskin krävde och tog bort alla som inte var lämpliga. till exempel en flyttalsenhet togs bort, vilket inte skulle behövas i denna applikation. Mer kritiskt tog de också bort många av instruktionerna som fungerade på data i huvudminnet och lämnade bara de instruktioner som fungerade på de interna processorregistren , eftersom dessa var mycket snabbare att använda och den enkla koden i en telefonväxel kunde skrivas för att användas endast dessa typer instruktioner. Resultatet av detta arbete var en konceptuell design för en förenklad processor med den prestanda som krävs.

Telefonväxelprojektet avbröts 1975, men teamet hade gjort avsevärda framsteg med konceptet och i oktober beslutade IBM att fortsätta det som en allmän design. Utan något uppenbart projekt att koppla den till, beslutade teamet att kalla det "801" efter byggnaden de arbetade i. För den allmänna rollen började teamet överväga verkliga program som skulle köras på en typisk minidator . IBM hade samlat in enorma mängder statistisk data om prestandan för verkliga arbetsbelastningar på sina maskiner och dessa data visade att över hälften av tiden i ett typiskt program ägnades åt att utföra endast fem instruktioner: ladda värde från minnet, lagra värde till minne, förgrening , jämför fastpunktsnummer och lägg till fastpunktsnummer. Detta antydde att samma förenklade processordesign skulle fungera lika bra för en minidator för allmänna ändamål som en switch för speciella ändamål.

Skäl mot användning av mikrokod

Denna slutsats flög i ansiktet på modern processordesign, som baserades på konceptet att använda mikrokod . IBM hade varit bland de första att använda denna teknik i stor utsträckning som en del av deras System/360 -serie. 360s och 370s kom i en mängd olika prestandanivåer som alla körde samma maskinspråkskod . På avancerade maskiner implementerades många av dessa instruktioner direkt i hårdvara, som en flyttalsenhet, medan low-end maskiner istället kunde simulera dessa instruktioner med en sekvens av andra instruktioner. binärt gränssnitt för en enda applikation att köra över hela linjen, och tillät kunderna att känna sig säkra på att om mer prestanda någonsin behövdes kunde de gå upp till en snabbare maskin utan några andra förändringar.

Mikrokod tillät en enkel processor att erbjuda många instruktioner, som hade använts av designers för att implementera en mängd olika adresseringslägen . Till exempel kan en instruktion som ADD ha ett dussin versioner, en som lägger till två siffror i interna register, en som lägger till ett register till ett värde i minnet, en som lägger till två värden från minnet, etc. Detta gjorde det möjligt för programmeraren att välja exakt variation som de behövde för en viss uppgift. Processorn skulle läsa den instruktionen och använda mikrokod för att dela upp den i en serie interna instruktioner. Till exempel, att lägga till två nummer i minnet kan implementeras genom att ladda dessa två nummer i register, lägga till dem och sedan spara dem igen.

Teamet märkte en bieffekt av detta koncept; när de stod inför överflöd av möjliga versioner av en given instruktion, kompilatorförfattare nästan alltid välja en enda version. Detta var nästan alltid den som implementerades i hårdvara på de billiga maskinerna. Det säkerställde att maskinkoden som genererades av kompilatorn skulle köras så snabbt som möjligt på hela sortimentet. Även om andra versioner av instruktioner kan köras ännu snabbare på en maskin som implementerade andra versioner av instruktionerna i hårdvara, gjorde komplexiteten att veta vilken man skulle välja på en ständigt föränderlig lista med maskiner detta extremt oattraktivt, och kompilatorförfattarna ignorerade till stor del dessa möjligheter.

Som ett resultat av detta användes majoriteten av instruktionerna i instruktionsuppsättningen aldrig i kompilerade program. Och det var här som teamet gjorde nyckelförverkligandet av 801-projektet:

Att införa mikrokod mellan en dator och dess användare medför en dyr kostnad för att utföra de vanligaste instruktionerna.

Mikrokod tar en tid som inte är noll för att undersöka instruktionen innan den utförs. Samma underliggande processor med mikrokoden borttagen skulle eliminera denna overhead och köra dessa instruktioner snabbare. Eftersom mikrokod i huvudsak körde små subrutiner dedikerade till en viss hårdvaruimplementering, utförde den i slutändan samma grundläggande uppgift som kompilatorn, och implementerade instruktioner på högre nivå som en sekvens av maskinspecifika instruktioner. Att helt enkelt ta bort mikrokoden och implementera den i kompilatorn kan resultera i en snabbare maskin.

En oro var att program skrivna för en sådan maskin skulle ta upp mer minne; vissa uppgifter som skulle kunna utföras med en enda instruktion på 370:an skulle behöva uttryckas som flera instruktioner på 801:an. Till exempel, att lägga till två nummer från minnet skulle kräva två laddning-till-register-instruktioner, en register-till-register-add. , och sedan ett lagra-till-minne. Detta skulle potentiellt kunna bromsa systemet totalt sett om det var tvungen att lägga mer tid på att läsa instruktioner från minnet än vad det tidigare tog att avkoda dem. När de fortsatte arbetet med designen och förbättrade sina kompilatorer, fann de att den totala programlängden fortsatte att minska och till slut blev ungefär samma längd som de som skrevs för 370.

Första implementeringar

Den ursprungligen föreslagna arkitekturen var en maskin med sexton 24-bitars register och utan virtuellt minne . Den använde ett tvåoperandformat i instruktionen, så att instruktionerna i allmänhet var av formen A = A + B , i motsats till treoperandformatet, A = B + C . Den resulterande CPU:n var i drift sommaren 1980 och implementerades med Motorola MECL-10K diskreta komponentteknologi på stora trådlindade specialkort. CPU:n klockades till 66 ns cykler (ungefär 15,15 MHz) och kunde beräkna med en snabb hastighet på cirka 15 MIPS .

801-arkitekturen användes i en mängd olika IBM-enheter, inklusive kanalkontroller för deras S/370 stordatorer (som IBM 3090 ), olika nätverksenheter och som en vertikal mikrokodexekveringsenhet i 9373- och 9375-processorerna i IBM 9370 stordatorfamiljen. Den ursprungliga versionen av 801-arkitekturen låg till grund för arkitekturen för IBM ROMP -mikroprocessorn som användes i IBM RT PC- arbetsstationsdatorn och flera experimentdatorer från IBM Research . En derivata av 801-arkitekturen med 32-bitars adressering vid namn Iliad var avsedd att fungera som den primära processorn för det misslyckade Fort Knox mellanregistersystemprojektet.

Senare ändringar

Efter att ha designats för ett system med begränsad funktion, saknade 801-designen ett antal funktioner som ses på större maskiner. Noterbart bland dessa var bristen på hårdvarustöd för virtuellt minne , som inte behövdes för kontrollrollen och som hade implementerats i mjukvara på tidiga 801-system som behövde det. För mer utbredd användning var hårdvarustöd en måste-funktion. Dessutom, på 1980-talet gick datorvärlden som helhet mot 32-bitarssystem , och det fanns en önskan att göra detsamma med 801.

Att flytta till ett 32-bitars format hade en annan betydande fördel. I praktiken visade det sig att tvåoperandformatet var svårt att använda i typisk matematisk kod. Helst skulle båda ingångsoperanderna finnas kvar i register där de kunde återanvändas i efterföljande operationer, men eftersom utdata från operationen skrev över en av dem var det ofta så att ett av värdena måste laddas om från minnet . Genom att gå över till ett 32-bitars format gjorde de extra bitarna i instruktionsorden det möjligt att specificera ett ytterligare register, så att utmatningen av sådana operationer kunde dirigeras till ett separat register. Det större instruktionsordet gjorde det också möjligt att öka antalet register från sexton till trettiotvå, en förändring som tydligt hade föreslagits genom granskning av 801-koden. Trots expansionen av instruktionsorden från 24 till 32-bitar, växte inte programmen med motsvarande 33% på grund av undvikna belastningar och besparingar på grund av dessa två ändringar.

Andra önskvärda tillägg inkluderar instruktioner för att arbeta med strängdata som kodades i "packat" format med flera ASCII- tecken i ett enda minnesord, och tillägg för att arbeta med binärkodade decimaler, inklusive en adderare som kan överföra fyra-bitars decimaltal .

När den nya versionen av 801 kördes som en simulator på 370:an, blev teamet förvånade över att finna att kod kompilerad till 801:an och kördes i simulatorn ofta kördes snabbare än samma källkod kompilerad direkt till 370 maskinkoden med hjälp av 370-talets PL/1 kompilator. När de porterade tillbaka sitt experimentella "PL.8"-språk till 370 och kompilerade applikationer med det, körde de också snabbare än befintlig PL/1-kod, så mycket som tre gånger så snabbt. Detta berodde på att kompilatorn tog RISC-liknande beslut om hur man kompilerar koden till interna register, och därigenom optimerar så många minnesåtkomster som möjligt. Dessa var lika dyra på 370:an som 801:an, men denna kostnad döljdes normalt av enkelheten med en enda rad med CISC-kod. PL.8-kompilatorn var mycket mer aggressiv när det gäller att undvika belastningar och besparingar, och resulterade därmed i högre prestanda även på en CISC-processor.

Cheetah, Panther och America-projekten

I början av 1980-talet kombinerades lärdomarna från 801:an med de från IBM Advanced Computer Systems- projektet, vilket resulterade i en experimentell processor kallad "Cheetah". Cheetah var en 2-vägs superskalär processor , som utvecklades till en processor kallad "Panther" 1985, och slutligen till en 4-vägs superskalär design kallad "America" ​​1986. Detta var en tre-chips processoruppsättning inklusive en instruktionsprocessor som hämtar och avkodar instruktioner, en fixpunktsprocessor som delar uppgiften med instruktionsprocessorn och en flyttalsprocessor för de system som kräver det. Designad av 801-teamet skickades den slutliga designen till IBMs kontor i Austin 1986, där den utvecklades till IBM RS/6000- systemet. RS/6000 som körde på 25 MHz var en av de snabbaste maskinerna på sin tid. Den överträffade andra RISC-maskiner med två till tre gånger på vanliga tester, och överträffade trivialt äldre CISC-system.

Efter RS/6000 riktade företaget uppmärksamheten mot en version av 801-koncepten som effektivt kunde tillverkas i olika skalor. Resultatet blev IBM POWER-instruktionsuppsättningsarkitekturen och PowerPC -avläggaren.

Erkännande

För sitt arbete på 801:an tilldelades John Cocke flera utmärkelser och medaljer:

Michael J. Flynn ser 801:an som den första RISC.

Citat

Bibliografi

Vidare läsning

  • "Att ändra datorarkitektur är ett sätt att öka genomströmningen, föreslår IBM-forskare". Electronics V. 49, N. 25 (23 december 1976), s. 30–31.
  • V. McLellan: "IBM Mini en radikal avgång". Datamation V. 25, N. 11 (oktober 1979), s. 53–55.
  • Dewar, Robert BK; Smosna, Matthew (1990). Mikroprocessorer: en programmerares syn . McGraw-Hill. s. 258–264.
  • Tabak, Daniel (1987). RISC-arkitektur . Research Studies Press. s. 69–72.

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=IBM_801&oldid=1133076429 "