IBM 801

De 801 was een experimentele centrale verwerkingseenheid (CPU), ontwikkeld door IBM in de jaren zeventig. De CPU wordt beschouwd als het eerste moderne RISC-ontwerp, dat voor alle berekeningen gebruik maakt van registergeheugen en de vele varianten om geheugen te adresseren elimineert die in CISC-ontwerpen voorkomen. De 801 werd oorspronkelijk ontwikkeld als processor voor een telefooncentrale, maar diende later als basis voor een minicomputer en een aantal producten voor de IBM mainframelijn. Het oorspronkelijke ontwerp was een 24-bits processor, maar dat werd al snel vervangen door 32-bits implementaties van dezelfde concepten. De oorspronkelijke 24-bits 801 werd gebruikt tot begin jaren tachtig.

De 801 was bijzonder invloedrijk in de computerindustrie. IBM kon aan de hand van enorme hoeveelheden statistische gegevens aantonen dat het eenvoudige ontwerp zelfs de krachtigste klassieke CPU-ontwerpen gemakkelijk kon overtreffen, terwijl het tegelijkertijd machinecode produceerde die slechts een fractie groter was dan de zwaar geoptimaliseerde CISC-instructies. Door dezelfde technieken toe te passen op bestaande processors, zoals bij het Systeem/370, werden over het algemeen ook de prestaties van die systemen verdubbeld. Dit demonstreerde de waarde van het RISC-concept. Alle toekomstige systemen van IBM waren gebaseerd op de principes die tijdens het 801-project waren ontwikkeld.

Voor zijn werk aan de 801 ontving John Cocke verschillende prijzen en medailles, waaronder de Turing Award in 1987, de National Medal of Technology in 1991 en de National Medal of Science in 1994.

Geschiedenis

Originele concepten

In 1974 begon IBM de mogelijkheid te onderzoeken om een telefooncentrale te bouwen die één miljoen oproepen per uur kon afhandelen, oftewel ongeveer 300 oproepen per seconde. Ze berekenden dat er 20.000 instructies nodig waren om elke oproep af te handelen. Wanneer ook timing-overhead en andere overwegingen in acht genomen werden, vereiste zo'n machine een prestatie van ongeveer 12 MIPS. Dat was bijzonder ambitieus aangezien het toenmalige topmodel van IBM, het System/370 Model 168 van eind 1972, ongeveer 3 MIPS leverde.

De groep die aan dit project werkte in het Thomas J. Watson Research Center, waaronder John Cocke, ontwierp voor dit doel een nieuwe processor. Om de vereiste prestaties te bereiken, onderzochten ze het soort bewerkingen die zo'n machine nodig had en verwijderden ze alle onderdelen die niet relevant waren. Dit leidde bijvoorbeeld tot het schrappen van een floating-point unit, die in deze toepassing niet nodig zou zijn. Wat nog belangrijker was: ze verwijderden ook veel van de instructies die werkten op gegevens in het hoofdgeheugen en lieten alleen de instructies over die werkten op de interne processorregisters, omdat deze veel sneller waren en omdat de relatief eenvoudige programmatie van een telefooncentrale zodanig geschreven kon worden dat er alleen van processorregisters gebruik gemaakt werd. Het resultaat van dit onderzoek was een conceptueel ontwerp voor een vereenvoudigde processor die de vereiste prestaties kon leveren.

Het telefooncentraleproject werd in 1975 geannuleerd, maar het team had aanzienlijke vooruitgang geboekt met het concept en in oktober besloot IBM het voort te zetten als een ontwerp voor algemene doeleinden. Omdat er geen duidelijk project was om het aan te koppelen, besloot het team het de "801" te noemen, naar het gebouw waarin ze werkten. Om te onderzoeken hoe de CPU ook voor algemene doeleinden zou kunnen gebruikt worden ging het team programma's analyseren die op een typische minicomputer konden uitgevoerd worden. IBM beschikte immers over enorme hoeveelheden statistische gegevens over de performantie van programma's op hun machines en deze gegevens toonden aan dat meer dan de helft van de tijd in een typisch programma werd besteed aan het uitvoeren van slechts vijf instructies: een waarde laden uit het geheugen, een waarde opslaan in het geheugen, vertakken, getallen vergelijken en getallen optellen. Dit suggereerde dat hetzelfde vereenvoudigde processorontwerp net zo goed zou werken voor een minicomputer voor algemeen gebruik als voor een telefooncentrale.

Reden om geen microcode te gebruiken

Deze conclusie druiste in tegen het toenmalige processorontwerp, dat gebaseerd was op het gebruik van microcode. IBM was een van de eersten die deze techniek op grote schaal gebruikte als onderdeel van hun IBM Systeem/360-serie. De 360 en 370 hadden verschillende prestatieniveaus die allemaal dezelfde machinetaal gebruikten. Op de geavanceerde modellen werden veel van deze instructies rechtstreeks in hardware geïmplementeerd, zoals een floating-point unit, terwijl instapmodellen die instructies konden simuleren met behulp van een reeks andere instructies gecodeerd in microcode. Hierdoor kon één binaire applicatie-interface over het hele assortiment gebruikt worden en konden de klanten erop vertrouwen dat als er ooit meer performantie nodig was, ze naar een snellere machine konden overstappen zonder hun programma's te moeten wijzigen.

Dankzij microcode kon een eenvoudige processor veel instructies bieden, die door de ontwerpers waren gebruikt om een grote verscheidenheid aan adresseringsmanieren te implementeren. Een instructie als ADD kan bijvoorbeeld een tiental versies hebben: één die twee getallen optelt in interne registers, één die een register toevoegt aan een waarde in het geheugen, één die twee waarden uit het geheugen optelt, enz. De processor zou de instructie lezen en microcode gebruiken om deze in een reeks interne instructies op te splitsen. Het optellen van twee getallen in het geheugen kan bijvoorbeeld worden geïmplementeerd door die twee getallen in registers te laden, ze op te tellen en de som vervolgens weer in het geheugen op te slaan. Het idee om alle mogelijke adresseringsmodi voor alle instructies aan te bieden werd een doel van processorontwerpers, en het concept werd bekend als een orthogonale instructieset.

Het 801-team merkte een neveneffect van dit concept op: wanneer ze geconfronteerd werden met de overvloed aan mogelijke versies van een bepaalde instructie, kozen de makers van compilers bijna altijd voor één enkele versie. Dit was bijna altijd degene die in de hardware op de low-end machines was geïmplementeerd. Dat zorgde ervoor dat de door de compiler gegenereerde machinecode zo snel mogelijk op het hele assortiment zou draaien. Hoewel het gebruik van andere versies van instructies misschien nog sneller zou kunnen werken op een machine die ze in hardware implementeerde, maakte de complexiteit van het weten welke te kiezen uit een steeds veranderende lijst van machines dit uiterst onaantrekkelijk, en auteurs van compilers negeerden deze mogelijkheden grotendeels.

Als gevolg hiervan werd het merendeel van de beschikbare instructies in de instructieset nooit gebruikt in gecompileerde programma's. Dit gaf aanleiding tot de belangrijkste bevinding van het 801-project:

Het gebruik van microcode tussen een computer en zijn gebruikers brengt dure overhead met zich mee bij het uitvoeren van de meest gebruikte instructies.

Microcode heeft tijd nodig om de instructie te onderzoeken voordat deze wordt uitgevoerd. Dezelfde onderliggende processor zonder microcode zou deze overhead elimineren en de instructie sneller uitvoeren. Omdat microcode in wezen kleine subroutines draaide op maat van een bepaalde hardware-implementatie, voerde deze uiteindelijk dezelfde basistaak uit als de compiler: instructies op een hoger niveau implementeren als een reeks machinespecifieke instructies. Het simpelweg verwijderen van de microcode en deze implementeren in de compiler kan resulteren in een snellere machine.

Er werd gevreesd dat dergelijke programma's meer geheugen in beslag zouden nemen omdat sommige taken die met een enkele instructie op de 370 konden uitgevoerd worden, meerdere instructies op de 801 zouden vereisen. Voor het optellen van twee getallen uit het geheugen zouden bijvoorbeeld twee laad-naar-register-instructies nodig zijn, een register-naar-register optelling en vervolgens een bewaar-in-geheugen. Dit zou het systeem in het algemeen kunnen vertragen als het meer tijd zou moeten besteden aan het lezen van instructies uit het geheugen dan voorheen nodig was om ze te decoderen. Terwijl men aan het ontwerp bleef werken en de compilers verbeterden, ontdekte men dat de totale programmalengte bleef afnemen en uiteindelijk ongeveer dezelfde lengte had als de programmalengte voor de 370.

Eerste implementaties

De aanvankelijk voorgestelde architectuur was een machine met zestien 24-bits registers en geen virtueel geheugen. Er werd een formaat gebruikt met twee operanden in de instructie, zodat instructies over het algemeen de vorm A = A + B hadden, in tegenstelling tot het formaat met drie operanden, A = B + C. De resulterende CPU was operationeel in de zomer van 1980, had een kloksnelheid van ongeveer 15,15 MHz en haalde een snelheid van ongeveer 15 MIPS.

De 801-architectuur werd gebruikt in onderdelen van diverse IBM-mainframes (waaronder de IBM 3090) en vormde ook de basis voor de architectuur van de IBM ROMP-microprocessor die werd gebruikt in het IBM RT PC-werkstation en in verschillende experimentele computers van IBM Research. Een afgeleide van de 801-architectuur met 32-bits adressering met de naam Iliad was bedoeld om te gebruiken als de primaire processor van het mislukte Fort Knox midrange-systeem.

Latere wijzigingen

Het 801-ontwerp was oorspronkelijk bedoeld voor een systeem met beperkte functionaliteit en miste een aantal functies die op grotere machines wel aanwezig waren. Er was bijvoorbeeld geen hardwareondersteuning voor virtueel geheugen, dat niet nodig was voor gebruik in telefooncentrales en dat in software geïmplementeerd werd op vroege 801-systemen die dit wel nodig hadden. Voor algemener gebruik was hardwareondersteuning een onmisbare functie. Bovendien was de computerwereld als geheel in de jaren tachtig op weg naar 32-bits systemen, en men wou hetzelfde doen met de 801.

De overstap naar een 32-bits formaat had nog een belangrijk voordeel. In de praktijk bleek dat het formaat met twee operanden moeilijk te gebruiken was in typische wiskundige programmacode. Idealiter zouden beide invoeroperands in registers blijven waar ze bij volgende bewerkingen opnieuw konden worden gebruikt, maar omdat de uitvoer van de bewerking een ervan overschreef, was het vaak zo dat een van de waarden opnieuw uit het geheugen moest worden geladen. Door naar een 32-bits formaat over te gaan maakten de extra bits in de instructiewoorden het mogelijk een extra register te specificeren, zodat de uitvoer van dergelijke bewerkingen naar een afzonderlijk register kon worden weggeschreven. Dankzij het grotere instructiewoord kon het aantal registers ook worden uitgebreid van zestien naar tweeëndertig, een verandering die resulteerde uit onderzoek van de 801-code. Ondanks de uitbreiding van de instructiewoorden van 24 naar 32 bits groeiden de programma's niet met de overeenkomstige 33% omdat als gevolg van deze twee veranderingen meerdere lees- en schrijfoperaties van en naar het geheugen konden vermeden worden.

Toen de nieuwe versie van de 801 als simulator op de 370 werd uitgevoerd, was het team verrast dat broncode die voor de 801 gecompileerd was en in de simulator uitgevoerd werd, vaak sneller werkte dan dezelfde broncode die rechtstreeks naar de 370-machinecode was gecompileerd door de PL/I-compiler van de 370. Toen ze hun experimentele "PL.8"-taal porteerden naar de 370 en er applicaties mee compileerden, werkten deze tot drie maal sneller dan de bestaande PL/I-code. Dit kwam doordat de compiler RISC-achtige beslissingen nam over hoe de code naar interne registers moest worden gecompileerd, waardoor de geheugentoegang zoveel mogelijk werd geoptimaliseerd. Geheugentoegang was op de 370 net zo complex als op de 801, maar deze kosten waren normaal gesproken niet zichtbaar door de eenvoud van een enkele regel CISC-code. De PL.8-compiler was veel agressiever in het vermijden van laden en opslaan, wat resulteerde in hogere prestaties, zelfs op een CISC-processor.

De Cheetah-, Panther- en America-projecten

Begin jaren tachtig werden de lessen die met de 801 waren geleerd gecombineerd met die van het IBM Advanced Computer Systems-project, wat resulteerde in een experimentele processor met de naam "Cheetah". Cheetah was een 2-weg superscalaire processor, die in 1985 uitgroeide tot een processor met de naam "Panther" en uiteindelijk tot een 4-weg superscalair ontwerp met de naam "America" in 1986. Dit was een processorset met drie chips, inclusief een instructieprocessor die instructies ophaalt en decodeert, een processor voor berekeningen met vastekommagetallen die de taak deelt met de instructieprocessor en een processor voor berekeningen met drijvendekommagetallen voor de systemen die dit nodig hebben. Het definitieve ontwerp, uitgewerkt door het 801-team, werd in 1986 naar het IBM-kantoor in Austin gestuurd, waar het werd ontwikkeld tot het IBM RS/6000-systeem. De RS/6000 met een snelheid van 25 MHz was een van de snelste machines van zijn tijd. Het systeem presteerde twee tot drie keer beter dan andere RISC-machines bij algemene tests, en presteerde ook beter dan oudere CISC-systemen.

Na de RS/6000 richtte het bedrijf zijn aandacht op een versie van de 801-concepten die efficiënt op verschillende schaalniveaus kon worden vervaardigd. Het resultaat was de IBM POWER-instructiesetarchitectuur en de daarvan afgeleide PowerPC.

Externe links

• The 801 Minicomputer - An Overview
• IBM System 801 Principles of Operation, Version 2
• 801 I/O Subsystem Definition
• IBM Archives: A Brief History of RISC, the IBM RS/6000 and the IBM eServer pSeries