Unisys 2200-seriens systemarkitektur

Figuren visar en högnivåarkitektur för OS 2200- systemet som identifierar viktiga hårdvaru- och mjukvarukomponenter. Majoriteten av Unisys-mjukvaran ingår i modellens delsystem och applikationsområde. Till exempel är databashanterarna delsystem och kompilatorerna är applikationer.

Systemgrunderna

Detaljerna om systemarkitekturen behandlas i Unisys publikation 3850 7802 Instruction Processor Programmering Reference Manual . Se även UNIVAC 1100/2200-serien .

1100-serien har använt ett 36-bitars ord med 6-bitars tecken sedan 1962. 36-bitars beräkningar drevs av en önskan att bearbeta 10-siffriga positiva och negativa tal. Militären behövde också kunna beräkna exakta banor, designa broar och utföra andra tekniska och vetenskapliga beräkningar, de behövde mer än 32 bitars precision. Ett 32-bitars flyttalsnummer gav endast cirka 6 siffrors noggrannhet medan ett 36-bitars tal gav de 8 siffrorna av noggrannhet som accepterades som minimikrav. Eftersom minne och lagringsutrymme och kostnader drev systemet, var det helt enkelt inte acceptabelt att gå till 64 bitar i allmänhet. Dessa system använder ens komplementaritmetik , vilket inte var ovanligt på den tiden. Nästan alla dåtidens datortillverkare levererade 36-bitarssystem med 6-bitars tecken inklusive IBM , DEC , General Electric och Sylvania .

Den 6-bitars teckenuppsättning som används av 1100-serien är också en DoD-uppsättning. Det definierades av Army Signal Corps och kallades Fieldata (data som returnerades från fältet). 1108 gav ett 9-bitars teckenformat för att stödja ASCII och senare ISO 8-bitars uppsättningar, men de användes inte i stor utsträckning förrän på 1980-talet igen på grund av utrymmesbegränsningar.

Arkitekturen i 2200-serien tillhandahåller många register . Basregister innehåller logiskt sett en virtuell adress som pekar på ett ord i en kod eller databank (segment). De kan peka på början av banken eller på vilket ord som helst inom banken. Indexregister används av instruktioner för att modifiera offset för det specificerade eller antagna basregistret. Enkel aritmetik (lägg till, subtrahera) kan utföras på alla indexregister. Dessutom består indexregister av en nedre offsetdel och en övre inkrementdel. En instruktion kan både använda offsetvärdet i ett indexregister som en del av en adress och specificera att inkrementet ska läggas till offseten. Detta gör att loopar kan utföras med färre instruktioner eftersom ökning av indexet med stegstorleken kan åstadkommas utan en separat instruktion. Aritmetiska register tillåter hela uppsättningen av beräkningsinstruktioner inklusive alla flyttalsoperationer. Vissa av dessa instruktioner fungerar på intilliggande registerpar för att utföra dubbelprecisionsoperationer. Det finns inga jämna udda begränsningar. Alla två register kan användas som ett dubbelprecisionsvärde. Fyra av de aritmetiska registren är också indexregister (mängderna överlappar varandra – indexregister X12 är aritmetiskt register A0). Detta gör att hela spektrumet av beräkningar kan utföras på index utan att behöva flytta resultaten. Resten av registren, så kallade R-register, används som snabb tillfällig lagring och för vissa specialfunktioner. R1 håller upprepningsantalet för de instruktioner som kan upprepas (blockera överföring, exekvera upprepade, etc.). R2 innehåller en bitmask för några instruktioner som utför en bitvis logisk operation utöver några andra funktioner (t.ex. maskerad last övre)

Det finns två fullständiga uppsättningar av register (A, X, R och B). En uppsättning, användaren registrerar, används av alla applikationer och de flesta delar av operativsystemet. Den sparas och återställs som en del av aktivitets (tråd) tillstånd. Den andra uppsättningen, Exec-registren, används av avbrottsbehandlingsrutiner och vissa andra delar av operativsystemet som vill undvika att behöva spara och återställa användarregister. Exec-registren är inte skrivbara av användarapplikationer även om viss användarkod kan läsa dem. Som ett resultat är Exec noggrant utformad för att aldrig lämna privat, säker eller konfidentiell information i register. Instruktionstolkning väljer den lämpliga registeruppsättningen att använda baserat på en bit i Processor State Register. Denna bit ställs alltid in (ändras till privilegierad) vid ett avbrott. Alla register är också synliga i adressutrymmet, men Exec-delen är skyddad och en referens med icke-privilegierad kod kommer att resultera i ett felavbrott.

2200-serien använder ett 36-bitars segmenterat virtuellt adressutrymme. Vi ska titta på adresseringsarkitekturen senare.

2200-serien är ett CISC- arkitektursystem. Det finns inte bara ett stort antal instruktioner (nuvarande antal är cirka 245) utan många av dem har adresseringsvarianter. Vissa av varianterna är kodade direkt i instruktionsformatet (delvisa ordreferenser) och några är beroende av Processor State Register-inställningar. Många instruktioner utför också mycket komplexa funktioner som en som implementerar en stor del av COBOL EDIT-verbet.

Ovanstående figur visar några av arkitekturens byggstenar. "Data" och "COMM" är två av de primära exemplen på mjukvaruundersystem som lever i en skyddsring mellan den för en användarapplikation och Exec. Det finns många andra sådana delsystem och användare skriver sina egna.

Minne och adressering

Nivå

Som nämnts tidigare använder 2200-serien en 36-bitars segmenterad virtuell adress. Den ursprungliga uppfattningen om ett segmenterat utrymme kom från den tidigaste implementeringen som betonade kod- och dataseparation för prestanda och användningen av delade kodbanker. Under årens lopp har detta utökats för att ge större flexibilitet vad gäller delningsnivåer och mycket bättre skydd för säkerhet och tillförlitlighet. Kontrollerad tillgång till delad data infördes också.

En virtuell adress består av tre delar. De 3 bitarna av hög ordning definierar delningsnivån. Detta är hjärtat i hela adresserings- och skyddssystemet. Varje tråd har åtta Bank Descriptor Tables (Segment Descriptor Tables i branschen) baserade på B16-B23. Tabellerna är indexerade efter nivå – nivå 0 hänvisar till Bank Descriptor Table (BDT) baserad på B16, nivå 2 BDT baserad på B18, etc. BDT på nivå 0 och nivå 2 är gemensamma för alla trådar i systemet. Varje körning (process) har sin egen nivå 4 BDT, och den BDT är gemensam för alla trådar i körningen. Varje användartråd har sin egen odelade nivå 6 BDT.

Aktivitet

Varje aktivitet i utökat läge (tråd) har alltid sex banker, segment, som är helt unika för den. En är returkontrollstacken som innehåller information om den anropande strukturen inklusive alla säkerhetsrelevanta rättigheter och tillståndsändringar. Det är inte tillgängligt via tråden förutom genom att använda CALL, RETURN och liknande instruktioner. Detta är en viktig del av skydds- och tillförlitlighetsmekanismen. Applikationer kan inte orsaka dåliga effekter genom att ändra returadresserna eller skriva över returkontrollstacken.

En annan unik bank är den automatiska lagringsbanken (Activity Local Store stack). Detta används av kompilatorerna för att hålla lokala variabler skapade i ett block. Den används också för att lagra alla parameterlistor som skickas på ett samtal. En av kontrollerna som görs av operativsystemet både för dess egen räkning och när ett anrop görs till ett skyddat delsystem är att säkerställa att operanderna finns på den trådlokala stacken och att tråden har rätt att komma åt den minnesregion som refereras till. med alla parametrar. Eftersom parametrarna hålls i trådlokalt utrymme finns det ingen chans att någon annan tråd kan ändra dem under eller efter valideringen. Det är den anropade procedurens ansvar att utföra liknande kontroller av eventuella sekundära parametrar som kan finnas i delat utrymme (dvs. den primära parametern pekar på en struktur som innehåller pekare). Proceduren förväntas kopiera sådana pekare till sitt eget lokala utrymme innan de valideras och sedan endast använda den internt validerade pekaren.

Aktiviteter kan skapa ytterligare segment upp till gränsen för det tillgängliga adressutrymmet (2 ³³ ord = 8GW eller cirka 36GB). Detta är ett bekvämt sätt för flertrådade applikationer att få stora mängder minnesutrymme i vetskap om att det är helt trådsäkert och att de inte tar något utrymme från resten av det som är tillgängligt för programmet. Varje aktivitet i ett program har sitt eget oberoende utrymme, vilket innebär att en applikation med säg 100 aktiviteter kan använda över 800GW (>3TB) virtuellt utrymme.

Baslägesaktiviteter börjar inte med några sådana banker eftersom baslägesprogram inte är medvetna om det virtuella adressutrymmet, men alla anrop till subsystem i utökat läge kommer att orsaka att dessa banker skapas.

Program

OS 2200 implementerar inte program på exakt samma sätt som UNIX , Linux och Windows implementerar processer, men det är den närmaste analogin. Den mest uppenbara skillnaden är att OS 2200 endast tillåter att ett enda program per körning (jobb, session) körs åt gången. Ett program kan ha hundratals trådar, men kan inte skapa andra program som körs samtidigt.

Det finns flera banker på programnivå som innehåller en blandning av Run (jobb, session) information och programinformation. Dessa är kontrollstrukturer för operativsystemet. De har ingen åtkomst eller skrivskyddad åtkomst för programmet. Program kan hämta information från vissa av dessa strukturer för felsökningsändamål eller för att hämta saker som användar-id och terminal-id utan att det krävs ett systemanrop. De kan inte skrivas av programmet. De innehåller saker som lagringsområden för trådtillstånd, filkontrollblock och redovisningsinformation.

Resten av bankerna används av programmet. När en programobjektfil exekveras, hämtar operativsystemet bankinformationen från filen och skapar banker efter behov och laddar bankens initialtillstånd från filen. Det enklaste programmet har en enda bank som innehåller kod och data. Detta anses vara mycket dåligt format, men är tillåtet för kompatibilitet med gamla applikationer. Du kan bara skapa en sådan applikation med assemblerspråk. Standardkompilatorerna skapar en eller flera kodbanker och en eller flera databanker. Normalt är kodbankerna markerade som skrivskyddade som ett felsöknings- och tillförlitlighetshjälpmedel. Det finns inga säkerhetsproblem på något sätt. Programmet kan bara påverka sig självt.

Varje program har alltså sitt eget adressutrymme skilt från alla andra program i systemet. Inget ett program kan göra kan ändra innehållet i något annat programs minne. OS och delade delsystem skyddas av andra mekanismer som kommer att diskuteras senare. Även läsåtkomst är förbjuden till OS och subsystemminne i nästan alla fall från kod i ett program. Det är möjligt att skapa ett delat delsystem som i allmänhet är läsbart, eller till och med skrivbart, av flera program, men det måste explicit installeras på det sättet av en privilegierad systemadministratör. Program skapas initialt med bara de banker som anges i objektfilen och med en enda aktivitet. De kan använda systemanrop för att skapa ytterligare banker inom sin egen programnivå och ytterligare aktiviteter.

Delsystem

Den närmaste analogin till ett delat delsystem är en .dll . Ett delsystem är ungefär som ett program i många avseenden förutom att det inte har några aktiviteter kopplade till sig. Istället nås den av andra program och delsystem, vanligtvis via en CALL-instruktion. Faktum är att ett program är ett delsystem plus en eller flera aktiviteter. Varje aktivitet tillhör ett "hem"-delsystem som är programmet som skapade den. Detta delsystemkoncept är viktigt som en inkapsling av åtkomsträttigheter och privilegier. Inom deras hemundersystem delar aktiviteter vanligtvis gemensamma åtkomsträttigheter till kod- och databanker. Kodbanker i hemundersystemet är vanligtvis skrivskyddade, eller till och med exekveringsbara om de inte innehåller några konstanta data, men alla aktiviteter kommer att ha rätt att utföra dem.

Delsystem är också kombinationer av banker och kan innehålla databanker såväl som kodbanker. Alla globalt delade delsystem måste installeras i systemet av någon med lämplig administratörsbehörighet. Undersystem kan också öppna filer. Databashanteraren är ett undersystem som öppnar alla databasfiler för dess användning, vanligtvis med exklusiva åtkomsträttigheter. Operativsystemet kommer att koppla sina egna banker till ett undersystem för att hålla filkontrolltabellerna.

OS

OS-nivån innehåller bankerna för Exec. Dessa banker är aldrig direkt tillgängliga för varken program eller globala delsystem. Ingångspunkter till operativsystemet hanteras alla på samma sätt som ett skyddat delsystem. Samtal till operativsystemet sker alltid via "gates", instruktioner som finns för det ändamålet (ER = Executive Request) eller via avbrott.

Bank Descriptor Index (BDI)

Nästa del av den virtuella adressen är BDI eller Bank Descriptor Index. Nivåfältet valde ett särskilt basregister för bankbeskrivningstabell (B16-B23). Basregister B16-B23 är en del av aktivitetstillståndet och underhålls av Exec utan direkt åtkomst av aktiviteten. Bank Descriptor-tabellerna för program- och aktivitetsnivåerna finns inom de programnivåbanker som tillhör operativsystemet.

BDI är helt enkelt ett index i en Bank Descriptor Table. Varje post i tabellen innehåller information om en bank. Varje sådan post beskriver upp till 1MB (256KW) virtuellt adressutrymme. När ett större sammanhängande utrymme behövs, kombineras på varandra följande poster logiskt för att skapa en större bank upp till maximalt 2 ³⁰ ord.

Bank Descriptor Table Entry (Bank Descriptor – BD) anger storleken på banken (liten = upp till 256KW, stor = upp till 16MW, mycket stor = upp till 1GW). En liten bank representeras alltid av en enda BD. Stora banker representeras av upp till 64 på varandra följande BD:er och en mycket stor bank med upp till 4096 BD:er. Stora och mycket stora banker behöver inte använda alla 64 eller 4096 på varandra följande BD:er. De använder bara så många som behövs för att tillhandahålla det virtuella adressutrymme som krävs. Posten innehåller också övre och nedre gränser för tillåtna offset inom banken. Virtuella adresser som ligger utanför gränserna genererar ett felavbrott. Detta tillåter små banker, till exempel som innehåller ett meddelande, att bara ha det virtuella utrymme reserverat för det som de faktiskt behöver och ger en felsökningskontroll mot dåliga pekare och index.

BD:n innehåller också ett nyckelvärde och åtkomstkontrollfält. Fälten indikerar om läs-, skriv- eller exekveringstillstånd ges till instruktionsprocessorn (3 bitar). De särskilda åtkomstbehörigheterna (SAP) gäller endast för aktiviteter som utförs inom det ägande delsystemet (egentligen bara de med ett matchande nyckelvärde). General Access Permissions (GAP) gäller för alla andra och är vanligtvis noll (ingen åtkomst). Exec ställer in ett nyckelvärde i tillståndet för varje aktivitet som kan ändras av gate- och avbrottsövergångar.

Skyddsmekanismer

2200-seriens skyddsarkitektur använder tre delar av aktivitetstillstånd som återspeglas i hårdvarutillståndet. De är Processor Privilege (PP), Ring och Domain.

Processor Privilege styr möjligheten att exekvera privilegierade instruktioner och komma åt skyddade register och andra tillstånd. PP=0 används av Exec och ger full tillgång till alla instruktioner och privilegierat tillstånd. Exec-aktiviteter och användaraktiviteter som har använt en gate för att komma åt ett Exec API körs vid PP=0.

PP=1 begränsar de flesta privilegierade instruktionerna men tillåter läsning av dygnsklockorna och läsning av innehållet i några av de privilegierade registren. Inget av de privilegierade registren innehåller någon verkligt känslig information, men att tillåta allmän läsåtkomst kan lätt leda till oupptäckta fel i användarprogram. I princip vid PP=1 är instruktioner som kan ändra adresseringsmiljön, ändra klockorna, ändra instrumenteringstillstånd eller utföra I/O alla begränsade. PP=1 används sällan.

PP=2 är det normala användarläget och är tillstånd där all annan kod körs. Det är en ytterligare begränsning av PP=1.

Det finns också en PP=3 som ytterligare begränsar instruktionerna som ett användarprogram kan köra, men det används för närvarande inte eftersom för många befintliga program använde några av dessa instruktioner. Avsikten var att begränsa åtkomsten till instruktioner som kan vara systemmodellberoende.

Domänmekanismen är hjärtat i skyddsmekanismen. Varje BD (bankdeskriptor) har ett låsfält som består av ett ringnummer och ett domännummer. Det finns också ett nyckelfält i tillståndet för varje aktivitet. Om nyckeln matchar låset eller ringen i nyckeln är mindre än ringen i låset, har aktiviteten särskild åtkomstbehörighet. Annars har aktiviteten allmän åtkomstbehörighet.

Ring tillåter åsidosättande av domänskyddsmekanismen. Användarapplikationer körs på Ring=3. Skyddade delsystem körs på Ring=2. Detta ger dem tillgång till sina egna data samtidigt som de får tillgång till parametrar och data i den uppringande användarens utrymme. Observera att det fortfarande inte är möjligt för en tråd att få det skyddade delsystemet att komma åt någon annan användares utrymme eftersom endast denna tråds Bank Descriptor Tables används. Ring=0 används av operativsystemet och låter det komma åt sina egna data samtidigt som det kan komma åt parametrar som skickas från antingen användarprogram eller skyddade delsystem.

Portar är en annan del av skyddsmekanismen. En gate är en datastruktur som styr övergångar mellan domäner. En gate bor i en gatebank och hårdvaran tvingar fram att alla referenser till grindar måste vara till adresser med en korrekt offset (multipel av en gatestorlek) inom en gatebank. En gate innehåller måladressen, nya värden för PP, Ring och Domain, och kan innehålla en dold parameter som ska skickas till målet. Skyddade delsystem är inte direkt tillgängliga för andra delsystem. Istället måste ett delsystem begära att en gate byggs i dess gatebank för åtkomst till det delsystemet. Detta tillåter operativsystemet att utföra alla kontroller av åtkomstkontroll. Länkningssystemet kommer då att hitta portadressen som är associerad med en ingångspunkt. Faktum är att hela mekanismen vanligtvis hanteras transparent inom länkningssystemet. Den dolda parametern tillåter till exempel en fil-I/O-grind att innehålla adressen eller handtaget för filkontrollblocket. Eftersom detta garanterat är korrekt eftersom det skapades av operativsystemet när användaren öppnade filen, kan många felkontroller elimineras från sökvägslängden för att göra I/O.

Instruktionsprocessorer

OS 2200 är designat för att hantera upp till 32 instruktionsprocessorer (eller processorer ). En hel del design har gjorts under åren för att optimera för denna miljö. Till exempel använder OS 2200 nästan ingen kritiska sektioner i sin design. Det är för hög sannolikhet att flera processorer kör samma kod. Istället använder den datalåsning på bästa möjliga granularitetsdata. I allmänhet hanterar lås en enskild instans av ett dataobjekt (t.ex. aktivitetskontrollstruktur eller filkontrollblock) och finns i objektets datastruktur. Detta minimerar sannolikheten för konflikter. När fler globala lås måste ställas in som vid uppdatering av en lista med objekt, ställs låset bara in så länge det tar att uppdatera länkarna i listan. Även utskick sker med separata lås för olika prioritetsnivåer. En kontroll kan göras för en tom prioritetsnivå utan att låsa. Låset behöver bara ställas in när du lägger till eller tar bort ett objekt från kön.

Registeruppsättningen finns i det synliga adressutrymmet. Register tycks finnas i de första 128 orden (200 ₈ ) i den aktuella instruktionsbanken (B0) när de hänvisas till som en datapost. Detta innebär en begränsning för kompilatorer att inte placera några datakonstanter i de första 128 orden i en kodbank. Resultatet av detta är en utökning av instruktionsuppsättningen utan att kräva ytterligare operationskoder. Register-till-register-operationer åstadkommes med registerlagringsoperationskoderna.

Typiska instruktioner innehåller en funktionskod, målregistret (eller källregistret), ett indexregister, ett basregister och ett förskjutningsfält. När funktionskoden med dess kvalificerare indikerar omedelbar data, kombineras förskjutnings-, bas-, i- och h-fälten för att bilda ett enda 18-bitars omedelbart värde. Detta tillåter att ladda, addera, multiplicera, etc. med små konstanter för att eliminera en minnesreferens och tillhörande lagring.

Processortillstånd som fångat på en stack vid ett avbrott innehåller den information som behövs för att både återställa kontrollen till den avbrutna aktiviteten och för att bestämma typen av avbrott. Avbrott kan förekomma mitt i långa instruktioner och staten hanterar den möjligheten.

Grundläget är en annan hel form av instruktionsformat och adressering. Grundläget ger kompatibilitet med tidigare system tillbaka till 1108. För alla praktiska ändamål definierar hårdvaruarkitekturen reglerna för vilka adresser och instruktioner konverteras till ovanstående formulär. Den mest uppenbara skillnaden i grundläget är bristen på explicita B-register i instruktionerna. Istället finns det fyra implicit använda B-register (B12-B15). Det finns en komplex algoritm som använder gränserna för de banker som representeras av dessa B-register, operandadressen och B-registret inom vilka den aktuella instruktionen finns.

De mest intressanta instruktionerna i 2200-repertoaren är lås- och synkroniseringsinstruktionerna. Villkorlig ersättning är bekant och ganska lik Compare and Swap i Intel-arkitekturen. Dessa instruktioner får alltid exklusiv användning av minnet/cache-raden som innehåller det refererade ordet. TS och TSS kollar lite i det refererade ordet. Om biten är klar ställer de in den och fortsätter (TS) eller hoppar över (TSS). Om biten är inställd avbryter de antingen (TS) eller faller igenom till nästa instruktion (TSS). På ett TS-avbrott utför operativsystemet en av flera åtgärder beroende på instruktionssekvensen och aktivitetsprioritet. Realtid och Exec-aktiviteter får helt enkelt tillbaka kontrollen för att tillåta ett nytt försök om det inte finns en ännu högre prioriterad aktivitet som väntar. Antagandet är att låset är satt på en annan processor och snart kommer att rensas. Om det är en användaraktivitet som inte körs med realtidsprioritet kan den få sin prioritet tillfälligt reducerad och placeras tillbaka i utskickningsköerna.

Alternativt kan kodsekvensen indikera att Test & Set Queuing används. I det här fallet placerar operativsystemet aktiviteten i ett vänteläge och kedjar den till slutet av listan över aktiviteter som väntar på just det låset. Aktiviteter som rensar ett sådant lås kontrollerar om några väntar och meddela i så fall operativsystemet för att tillåta en av fler att försöka igen. Test & Set Queuing används vanligtvis för synkronisering inom delsystem som databashanteraren där aktiviteter från många program kan köras.

Resultatet av dessa mekanismer är mycket effektiv, låg overhead, synkronisering mellan aktiviteter.

Köarkitekturen är ett annat intressant specialfall. Den var speciellt utformad för att möjliggöra mycket effektiv hantering av meddelanden där antalet meddelanden som väntar på behandling kan vara nästan obegränsat. Det syftar också till att minska en av de primära kostnaderna för meddelanden, nämligen att ständigt behöva flytta runt meddelanden i minnet. Även att flytta dem från kommunikationshanteraren till meddelandekösubsystemet till bearbetningsprogrammet elimineras. Istället placeras varje meddelande i en liten egen bank. Instruktioner tillåter att placera bankbeskrivningarna för dessa banker i en kö och ta bort dem från en kö. När ett meddelande placeras i en kö har det sändande programmet eller delsystemet inte längre tillgång till det. Den banken tas bort från sitt adressutrymme. När ett meddelande hämtas från en kö blir banken en del av mottagarens adressutrymme. Köinstruktionerna tillhandahåller även aktivitetssynkroniseringsfunktioner (t.ex. vänta på ett meddelande).

Endast "pekare" flyttas och de flyttas på ett sätt som säkerställer säkerhet och integritet. När det har flyttats är informationen i meddelandet endast synlig för mottagaren.

I/O-processorer

Alla I/O-system i 2200-serien hanteras av I/O-processorer . Dessa processorer avlastar stora delar av I/O-vägens längd och återhämtning, och genom att helt isolera huvudsystemet från I/O-fel, avbrott, bussfel, etc. förbättrar tillförlitligheten och tillgängligheten avsevärt. I/O-processorerna finns i tre olika typer (Storage, Communications, Clustering) men den enda verkliga skillnaden är firmwarebelastningen .

Alla I/O-processorer styrs av operativsystemet. OS 2200 tillhandahåller ett råläge för I/O som kallas "godtycklig enhets I/O", men även där validerar operativsystemet att programmet har åtkomst till en tillåten enhet och hanterar alla avbrott och fel innan lämplig status skickas vidare till programmet. Program måste ges privilegier av säkerhetsansvarig för att komma åt enheter i godtyckligt läge och som kan begränsas av både säkerhetsansvarig och systemoperatör till specifika enheter. Godtycklig I/O är inte tillåten till en enhet som också används av något annat program eller systemet. Enheten måste exklusivt allokeras till programmet.

OS tar mycket allmänna anrop från program och genererar kommandopaket med riktiga minne och enhetsadresser som sedan skickas till I/O-processorn. Firmware i I/O-processorn skapar faktiskt de enhetsspecifika (t.ex. SCSI ) paketen, ställer in DMA , utfärdar I/O och servar avbrotten.