Burroughs store systemer - Burroughs large systems

Den Burroughs Large Systems Group produserte en familie av store 48-bits middel ved hjelp stabel maskinens instruksjonssett med tette stavelser . Den første maskinen i familien var B5000 i 1961. Den ble optimalisert for å kompilere ALGOL 60- programmer ekstremt godt ved bruk av enpass-kompilatorer. Det utviklet seg til B5500. Påfølgende store redesigner inkluderer B6500/B6700 -linjen og dens etterfølgere, samt den separate B8500 -linjen.

På 1970-tallet ble Burroughs Corporation organisert i tre divisjoner med svært forskjellige produktlinjearkitekturer for avanserte datasystemer for avanserte, mellomstore og inngangsnivåer. Hver divisjons produktlinje vokste fra et annet konsept for hvordan man kan optimalisere datamaskinens instruksjonssett for bestemte programmeringsspråk. "Burroughs Large Systems" refererte til alle disse produktsystemene med store systemer sammen, i motsetning til COBOL- optimaliserte mellomstore systemer (B2000, B3000 og B4000) eller de fleksible arkitekturen Small Systems (B1000).

Bakgrunn

Burroughs ble grunnlagt på 1880 -tallet og var det eldste kontinuerlige driftsselskapet innen databehandling ( Elliott Brothers ble grunnlagt før Burroughs, men laget ikke dataenheter på 1800 -tallet). På slutten av 1950 -tallet var databehandlingsutstyret fortsatt begrenset til elektromekaniske regnskapsmaskiner som Sensimatic . Det hadde ingenting å konkurrere med sine tradisjonelle rivaler IBM og NCR , som hadde begynt å produsere større datamaskiner, eller med nylig grunnlagt Univac . I 1956 kjøpte de et tredjepartsfirma og merket designet på nytt som B205.

Burroughs 'første internt utviklede maskin, B5000, ble designet i 1961, og Burroughs prøvde å løse sin sene inntreden i markedet med strategien om et helt annet design basert på de mest avanserte databehandlingsideene som var tilgjengelige på den tiden. Mens B5000 -arkitekturen er død, inspirerte den B6500 (og påfølgende B6700 og B7700). Datamaskiner som bruker den arkitekturen var fremdeles i produksjon som Unisys ClearPath Libra -servere som kjører en utviklet, men kompatibel versjon av MCP -operativsystemet som først ble introdusert med B6700. Den tredje og største linjen, B8500, hadde ingen kommersiell suksess. I tillegg til en proprietær CMOS -prosessordesign, bruker Unisys også Intel Xeon -prosessorer og kjører MCP- , Microsoft Windows- og Linux -operativsystemer på Libra -serverne; bruken av egendefinerte sjetonger ble gradvis eliminert, og innen 2018 hadde Libra -serverne strengt tatt vare på Intel i noen år.

B5000

Det første medlemmet i den første serien, B5000, ble designet fra 1961 av et team under ledelse av Robert (Bob) Barton . Den hadde en uvanlig arkitektur. Det har blitt oppført av databehandlingsforskeren John Mashey som en av arkitekturen han beundrer mest. "Jeg har alltid trodd at det var et av de mest innovative eksemplene på kombinert hardware/software -design jeg har sett, og langt foran sin tid." B5000 ble etterfulgt av B5500 (som brukte disker i stedet for trommelagring) og B5700 (som tillot at flere CPUer ble gruppert rundt delt disk). Selv om det ikke var noen etterfølger til B5700, påvirket B5000 -linjen designet på B6500 sterkt, og Burroughs overførte Master Control Program ( MCP ) til den maskinen.

Funksjoner

  • All kode automatisk innadgående (figur 4.5 fra ACM Monograph viser i et nøtteskall hvorfor): programmerere ikke trenger å gjøre noe mer for å ha noen kode på alle språk spredt over prosessorer enn å bruke bare de to vist enkle primitiver. Dette skyldes disse hovedtrekkene i denne arkitekturen:
    • Delvis datadrevet merket og deskriptorbasert design
    • Maskinvare ble designet for å støtte programvarekrav
    • Maskinvare designet for utelukkende å støtte programmeringsspråk på høyt nivå
    • Ingen forsamlingsspråk eller montør; all systemprogramvare skrevet i et utvidet utvalg av ALGOL 60 . Men ESPOL hadde uttalelser for hver av stavelser i arkitekturen.
    • Få programmerere tilgjengelig registre
    • Forenklet instruksjonssett
    • Stabelmaskin der alle operasjoner bruker stabelen i stedet for eksplisitte operander. Denne tilnærmingen har nå falt i unåde.
    • Alle avbrudd og prosedyreanrop bruker stabelen
    • Støtte for et operativsystem (MCP, Master Control Program )
  • Støtte for asymmetrisk (master/slave) multiprosessering
  • Støtte for andre språk som COBOL
  • Kraftig strengmanipulasjon
  • Et forsøk på en sikker arkitektur som forbyr uautorisert tilgang til data eller forstyrrelser i driften
  • Tidlig feilsøking som støtter utvikling og testing av programvare
  • Et kommersielt virtuelt minne for implementering, bare foregående av Ferranti Atlas . </ref> <
  • Første segmenterte minnemodell
  • Etterfølgere eksisterer fortsatt i Unisys ClearPath/MCP -maskiner

System design

B5000 var uvanlig den gangen ved at arkitekturen og instruksjonssettet ble designet med behovet til programvare tatt i betraktning. Dette var en stor avvik fra datidens datasystemdesign, der en prosessor og instruksjonssett ble designet og deretter overlevert til programvarefolkene.

B5000, B5500 og B5700 i Word -modus har to forskjellige adressemoduser, avhengig av om det kjører et hovedprogram (SALF av) eller en underprogram (SALF på). For et hovedprogram er T -feltet i en Operand Call eller Descriptor Call stavelse i forhold til Program Reference Table (PRT). For underrutiner er typen adressering avhengig av de tre høye bitene av T og av Mark Stack FlipFlop (MSFF), som vist i B5x00 Relative Addressing .

B5x00 Relativ adressering
SALV T0
A38 		T1
A39 		T2
A40 		MSFF Utgangspunkt Innhold Indeksskilt Indeks
Bits 		Maks
indeks
AV - - - - R Adresse til PRT + T 0-9
A 38-47 		1023
PÅ AV - - - R Adresse til PRT + T 1-9
A 39-47 		511
PÅ PÅ AV - AV F Adresse til siste RCW eller MSCW på bunken + T 2-9
A 40-47 		255
PÅ PÅ AV - PÅ (R+7) F registrer deg fra MSCW ved PRT+7 + T 2-9
A 40-47 		255
PÅ PÅ PÅ AV - C Adresse til gjeldende instruksjonsord + T 3-9
A 41-47 		127
PÅ PÅ PÅ PÅ AV F Adresse til siste RCW eller MSCW på bunken - T 3-9
A 41-47 		127
PÅ PÅ PÅ PÅ PÅ (R+7) F registrer deg fra MSCW ved PRT+7 - T 3-9
A 41-47 		127
Merknader:

Språkstøtte

B5000 ble designet for å utelukkende støtte språk på høyt nivå. Dette var på et tidspunkt da slike språk bare ble fremtredende hos FORTRAN og deretter COBOL . FORTRAN og COBOL ble av noen ansett som svakere språk når det gjelder moderne programvareteknikker, så et nyere, for det meste uprøvd språk ble tatt i bruk, ALGOL-60 . ALGOL -dialekten som ble valgt for B5000 var Elliott ALGOL , først designet og implementert av CAR Hoare på en Elliott 503 . Dette var en praktisk forlengelse av ALGOL med I/O -instruksjoner (som ALGOL hadde ignorert) og kraftige instruksjoner for strengbehandling. Hoares berømte Turing Award -foredrag var om dette emnet.

Dermed var B5000 basert på et veldig kraftig språk. Donald Knuth hadde tidligere implementert ALGOL 58 på en tidligere Burroughs -maskin i løpet av de tre månedene av sommerferien, og han var perifer involvert i B5000 -designet som konsulent. Mange avskrev ALGOL og trodde feilaktig at språk på høyt nivå ikke kunne ha samme kraft som assembler, og dermed ikke realisert ALGOLs potensial som systemprogrammeringsspråk.

Burroughs ALGOL -kompilatoren var veldig rask - dette imponerte den nederlandske forskeren Edsger Dijkstra da han sendte inn et program som skulle kompileres ved B5000 Pasadena -anlegget. Kortstokken hans ble samlet nesten umiddelbart, og han ønsket umiddelbart flere maskiner til universitetet hans, Eindhoven University of Technology i Nederland. Kompilatoren var rask av flere grunner, men den primære årsaken var at den var en enpass-kompilator . Tidlige datamaskiner hadde ikke nok minne til å lagre kildekoden, så kompilatorer (og til og med montører) trengte vanligvis å lese kildekoden mer enn én gang. Burroughs ALGOL -syntaksen, i motsetning til det offisielle språket, krever at hver variabel (eller et annet objekt) deklareres før den brukes, så det er mulig å skrive en ALGOL -kompilator som leser dataene bare én gang. Dette konseptet har dype teoretiske implikasjoner, men det tillater også veldig rask kompilering. Burroughs store systemer kunne kompilere så fort de kunne lese kildekoden fra hullene , og de hadde de raskeste kortleserne i bransjen.

Den kraftige Burroughs COBOL-kompilatoren var også en en-pass-kompilator og like rask. Et COBOL-program på 4000 kort, kompilert så raskt som 1000-kort/minutt-leserne kunne lese koden. Programmet var klart til bruk så snart kortene gikk gjennom leseren.

Figur 4.5 Fra ACM -monografien i referansene. Elliot Organick 1973.

B6500 og B7500

Se også: Burroughs B6x00-7x00 instruksjonssett

B6500 (levering i 1969) og B7500 var de første datamaskinene i den eneste serien av Burroughs -systemer som overlevde til i dag. Mens de ble inspirert av B5000, hadde de en helt ny arkitektur. Blant de viktigste forskjellene var

B6700 og B7700

Blant andre kunder var alle fem New Zealand -universitetene i 1971.

B8500

B8500 -linjen stammer fra D825, en militær datamaskin som var inspirert av B5000.

B8500 ble designet på 1960 -tallet som et forsøk på å slå sammen designene B5500 og D825. Systemet brukte monolitiske integrerte kretser med magnetisk tynnfilmsminne . Arkitekturen brukte et 48-biters ord, en stabel og deskriptorer som B5500, men ble ikke annonsert som oppadgående. B8500 kunne aldri få pålitelig arbeid, og prosjektet ble kansellert etter 1970, og hadde aldri levert et ferdig system.

Historie

Det sentrale konseptet med virtuelt minne dukket opp i designene til Ferranti Atlas og Rice Institute Computer , og de sentrale begrepene deskriptorer og merket arkitektur dukket opp i designet av Rice Institute Computer på slutten av 1950 -tallet. Selv om disse designene hadde en direkte innflytelse på Burroughs, var arkitekturen til B5000, B6500 og B8500 veldig forskjellige fra Atlas og Rice -maskinen; de er også veldig forskjellige fra hverandre.

Det første av Burroughs store systemer var B5000. Designet i 1961, var det en andre generasjons datamaskin som bruker diskret transistorlogikk og magnetisk kjerne minne . De første maskinene som erstattet B5000 -arkitekturen var B6500 og B7500. Etterfølgermaskinene fulgte maskinvareutviklingstrendene for å implementere arkitekturen på nytt i ny logikk i løpet av de neste 25 årene, med B5500, B6500, B5700, B6700, B7700, B6800, B7800 og til slutt Burroughs A-serien. Etter en fusjon der Burroughs kjøpte Sperry Corporation og endret navn til Unisys , fortsatte selskapet å utvikle nye maskiner basert på MCP CMOS ASIC . Disse maskinene var Libra 100 gjennom Libra 500, og Libra 590 ble kunngjort i 2005. Senere har Libras, inkludert 590, også Intel Xeon -prosessorer og kan kjøre Burroughs store systemarkitektur både i emulering og på MCP CMOS -prosessorer . Det er uklart om Unisys vil fortsette utviklingen av nye MCP CMOS ASIC.

Burroughs (1961–1986)
B5000 1961 første system, 2. generasjon (transistor) datamaskin
B5500 1964 3x hastighetsforbedring
B6500 1969 Tredje generasjons datamaskin (integrerte kretser), opptil 4 prosessorer
B5700 1971 nytt navn på B5500
B6700 1971 nytt navn/feilrettelse for B6500
B7700 1972 raskere prosessor, cache for stabel, opptil 8 forespørsler (I/O eller sentrale prosessorer) i en eller to partisjoner.
B6800 1977? halvlederminne, NUMA -arkitektur
B7800 1977? halvlederminne, raskere, opptil 8 forespørere (I/O eller sentrale prosessorer) i en eller to partisjoner.
B5900 1980? halvlederminne, NUMA -arkitektur. Maks 4 B5900 -prosessorer bundet til et lokalt minne og et felles Global Memory II (tm)
B6900 1979? halvlederminne, NUMA -arkitektur. Maks 4 B6900 -prosessorer bundet til et lokalt minne og et felles globalt minne (tm)
B7900 1982? halvlederminne, raskere, kode- og datacacher, NUMA -arkitektur,

1-2 HDUer (I/O), 1-2 APs, 1-4 CPUer, myk implementering av NUMA-minne tillot CPUer å flyte fra minneplass til minneplass.

A9/A10 1984 B6000-klasse, Første pipelinerte prosessor i mellomklassen, enkelt CPU (dobbel på A10), Først for å støtte eMode Beta (utvidet minneadressering)
A12/A15 1985 B7000 klasse, Re-implementert i spesialdesignede Motorola ECL MCA1, så MCA2 gate arrays , enkelt CPU enkelt HDU (A12) 1-4 CPU, 1-2 HDU (A15)
Unisys (1986 - i dag)
Micro A. 1989 stasjonær "mainframe" med en-brikke SCAMP-prosessor.
Clearpath HMP NX 4000 1996? ??
Clearpath HMP NX 5000 1996? ??
Clearpath HMP LX 5000 1998 Implementerer Burroughs Store systemer bare i emulering ( Xeon -prosessorer)
Vekten 100 2002? ??
Vekten 200 200? ??
Vekten 300 200? ??
Vekten 400 200? ??
Vekten 500 2005? f.eks. Vågen 595
Vekten 600 2006? ??
Vekten 700 2010 f.eks. Vekten 750

Primære maskinvarelinjer

Maskinvare- og programvaredesign, utvikling og produksjon ble delt mellom to hovedsteder, i Orange County, California og i utkanten av Philadelphia . Det første Large Systems Plant, som utviklet B5000 og B5500, lå i Pasadena, California, men flyttet til City of Industry, California , hvor det utviklet B6500. Orange County -beliggenheten, som var basert på et anlegg i Mission Viejo, California, men til tider inkluderte fasiliteter i nærliggende Irvine og Lake Forest , var ansvarlig for den mindre B6x00 -linjen, mens East Coast -operasjonen, basert i Tredyffrin, Pennsylvania , håndterte større B7x00 linje. Alle maskiner fra begge linjene var fullt objektkompatible, noe som betyr at et program som er samlet på en kan kjøres på en annen. Nyere og større modeller hadde instruksjoner som ikke ble støttet på eldre og tregere modeller, men maskinvaren påkalte en operativsystemfunksjon som tolket den når den oppdaget en ukjent instruksjon. Andre forskjeller inkluderer hvordan prosessbytte og I/O ble håndtert, og vedlikehold og kaldstartfunksjonalitet. Større systemer inkluderte maskinvare prosessplanlegging og mer kapable inngangs-/utdatamoduler, og mer svært funksjonelle vedlikeholdsprosessorer. Når Bxx00 -modellene ble erstattet av A -serie -modellene, ble forskjellene beholdt, men ikke lenger lett å identifisere etter modellnummer.

ALGOL

Hovedartikkel: ALGOL
Burroughs ALGOL
Paradigmer Multiparadigme : prosessuell , imperativ , strukturert
Familie ALGOL
Designet av John McClintock, andre
Utvikler Burroughs Corporation
Første gang dukket opp 1962 ; 59 år siden ( 1962 )
Plattform Burroughs store systemer
OS Burroughs MCP
Påvirket av
ALGOL 60
Påvirket
ESPOL , MCP , NEWP

Burroughs store systemer implementerer en ALGOL-avledet stabelarkitektur . B5000 var det første stabelbaserte systemet.

Selv om B5000 var spesielt designet for å støtte ALGOL, var dette bare et utgangspunkt. Andre forretningsorienterte språk som COBOL ble også godt støttet, særlig av de kraftige strengoperatørene som var inkludert for utvikling av raske kompilatorer.

ALGOL som brukes på B5000 er et utvidet ALGOL -delsett. Den inneholder kraftige instruksjoner for strengmanipulering, men utelukker visse ALGOL -konstruksjoner, spesielt uspesifiserte formelle parametere. En DEFINE -mekanisme tjener et lignende formål som #defines som finnes i C, men er fullstendig integrert i språket i stedet for å være en forbehandler. EVENT -datatypen letter koordinering mellom prosesser, og ON FAULT -blokker muliggjør håndtering av programfeil.

Brukernivået til ALGOL inkluderer ikke mange av de usikre konstruksjonene som operativsystemet og annen systemprogramvare trenger. To nivåer av språkutvidelser gir ytterligere konstruksjoner: ESPOL og NEWP for skriving av MCP og nært beslektet programvare, og DCALGOL og DMALGOL for å gi mer spesifikke utvidelser for spesifikke typer systemprogramvare.

ESPOL og NEWP

Opprinnelig ble B5000 MCP -operativsystemet skrevet i en forlengelse av utvidet ALGOL kalt ESPOL (Executive Systems Programming Oriented Language). Dette ble erstattet på midten til slutten av 70-tallet med et språk kalt NEWP . Selv om NEWP sannsynligvis bare betydde "Nytt programmeringsspråk", omgir legender navnet. En vanlig (kanskje apokryf) historie i Burroughs på den tiden antydet at den kom fra " Ingen Executive Washroom Privileges ." En annen historie er at rundt 1976, John McClintock fra Burroughs (programvareingeniøren som utviklet NEWP) kalte språket "NEWP" etter å ha blitt spurt, "har det et navn enda": ved å svare "nyoooop", antok han det som en Navn. NEWP var også en delsett ALGOL-utvidelse, men den var sikrere enn ESPOL, og droppet noen lite brukte kompleksiteter av ALGOL. Faktisk blir alle usikre konstruksjoner avvist av NEWP -kompilatoren med mindre en blokk er spesifikt merket for å tillate disse instruksjonene. Slik merking av blokker gir en beskyttelsesmekanisme på flere nivåer.

NEWP-programmer som inneholder usikre konstruksjoner, kan i utgangspunktet ikke kjøres. Sikkerhetsadministratoren for et system er i stand til å "velsigne" slike programmer og gjøre dem kjørbare, men normale brukere kan ikke gjøre dette. (Selv "privilegerte brukere", som vanligvis i hovedsak har rotrettigheter, kan kanskje ikke gjøre dette avhengig av konfigurasjonen som nettstedet har valgt.) Mens NEWP kan brukes til å skrive generelle programmer og har en rekke funksjoner designet for store programvareprosjekter , den støtter ikke alt ALGOL gjør.

NEWP har en rekke fasiliteter for å muliggjøre store programvareprosjekter, for eksempel operativsystemet, inkludert navngitte grensesnitt (funksjoner og data), grupper av grensesnitt, moduler og supermoduler. Moduler grupperer data og funksjoner sammen, noe som gir enkel tilgang til dataene som globale i modulen. Grensesnitt lar en modul importere og eksportere funksjoner og data. Supermoduler lar moduler grupperes.

DCALGOL og meldingskontrollsystemer (MCS)

Det andre mellomliggende sikkerhetsnivået mellom operativsystemkoden (i NEWP) og brukerprogrammer (i ALGOL) er for mellomprogrammer , som er skrevet i DCALGOL (datakommunikasjon ALGOL). Dette brukes til mottak og utsendelse av meldinger som fjerner meldinger fra inngangskøer og plasserer dem i køer for andre prosesser i systemet å håndtere. Middleware som COMS (introdusert rundt 1984) mottar meldinger fra hele nettverket og sender disse meldingene til spesifikke håndteringsprosesser eller til et MCS (Message Control System) som CANDE (" C ommand AND E dit," programutviklingsmiljøet).

MCS er programmer som er verdt å merke seg-de kontrollerer brukersesjoner og sørger for å holde oversikt over brukerstatus uten å måtte kjøre prosesser per bruker siden en enkelt MCS-stabel kan deles av mange brukere. Lastbalansering kan også oppnås på MCS -nivå. For eksempel å si at du vil håndtere 30 brukere per stabel, i så fall hvis du har 31 til 60 brukere, har du to stabler, 61 til 90 brukere, tre stabler, etc. Dette gir B5000 -maskiner en stor ytelsesfordel i en server siden du ikke trenger å starte en annen brukerprosess og dermed opprette en ny stabel hver gang en bruker kobler seg til systemet. Dermed kan du effektivt betjene brukere (enten de krever tilstand eller ikke) med MCS -er. MCS gir også ryggraden i storskala transaksjonsbehandling.

MCS snakket med en ekstern co-prosessor, DCP (Datacomm Control Processor). Dette var en 24-biters minidator med en konvensjonell registerarkitektur og maskinvare I/O-evne til å håndtere tusenvis av eksterne terminaler. DCP og B6500 kommunisert av meldinger i minnet, i hovedsak pakker i dagens termer, og MCS gjorde B6500-siden behandling av disse meldingene. I de første årene hadde DCP en assembler (Dacoma), et applikasjonsprogram som heter DCPProgen skrevet i B6500 ALGOL. Senere genererte NDL (Network Definition Language) kompilatoren DCP -koden og NDF (nettverksdefinisjonsfil). Det var en ALGOL -funksjon for hver type DCP -instruksjon, og hvis du kalte den funksjonen, ville de tilsvarende DCP -instruksjonsbitene bli sendt ut til utgangen. Et DCP -program var et ALGOL -program som bare består av en lang liste med samtaler på disse funksjonene, en for hver forsamlingsspråklæring. I hovedsak fungerte ALGOL som makropasset til en makromonterer. Det første passet var ALGOL -kompilatoren; det andre passet kjørte det resulterende programmet (på B6500) som deretter ville avgi binær for DCP.

DMALGOL og databaser

En annen variant av ALGOL er DMALGOL (Data Management ALGOL). DMALGOL er ALGOL utvidet for å kompilere DMSII -databaseprogramvaren fra databasebeskrivelsesfiler opprettet av DASDL -kompilatoren (Data Access and Structure Definition Language). Databasedesignere og administratorer kompilerer databasebeskrivelser for å generere DMALGOL -kode som er skreddersydd for tabellene og indeksene som er angitt. Administratorer trenger aldri å skrive DMALGOL selv. Vanlige programmer på brukernivå oppnår databasetilgang ved å bruke kode skrevet på applikasjonsspråk, hovedsakelig ALGOL og COBOL, utvidet med databaseinstruksjoner og direktiver for transaksjonsbehandling. Den mest bemerkelsesverdige egenskapen til DMALGOL er dens forbehandlingsmekanismer for å generere kode for håndtering av tabeller og indekser.

DMALGOL-forbehandling inkluderer variabler og sløyfer, og kan generere navn basert på kompileringstidsvariabler. Dette gjør det mulig å skreddersy langt utover det som kan gjøres ved forhåndsbehandlingsanlegg som mangler sløyfer.

DMALGOL brukes til å tilby skreddersydde tilgangsrutiner for DMSII -databaser. Etter at en database er definert ved hjelp av datatilgang og strukturdefinisjonsspråk (DASDL), blir skjemaet oversatt av preprosessoren til skreddersydde DMALGOL -tilgangsrutiner og deretter kompilert. Dette betyr at det i motsetning til andre DBMS-implementeringer ofte ikke er behov for databasespesifikk hvis/da/ellers-kode ved kjøretid. På 1970 -tallet ble denne "skreddersøm" veldig mye brukt for å redusere kodefotavtrykket og utførelsestiden. Det ble mye mindre brukt i senere år, dels fordi finjustering på lavt nivå for minne og hastighet ble mindre kritisk, og dels fordi eliminering av forbehandling gjorde kodingen enklere og dermed muliggjorde viktigere optimaliseringer. DMALGOL inkluderte verb som "finn", "lås", "lagre". Også verbene "begintransaction" og "endtraction" ble inkludert, noe som løste fastlåsesituasjonen når flere prosesser åpnet og oppdaterte de samme strukturene.

Roy Guck fra Burroughs var en av hovedutviklerne av DMSII .

I senere år, med størrelsen på kompilatorkoden mindre bekymringsfull, ble de fleste forhåndskonstruksjonskonstruksjonene gjort tilgjengelige på brukernivået til ALGOL. Bare de usikre konstruksjonene og den direkte behandlingen av databasebeskrivelsesfilen forblir begrenset til DMALGOL.

Stabelarkitektur

I mange tidlige systemer og språk ble programmerere ofte fortalt å ikke gjøre rutinene for små. Anrop og retur av prosedyrer var dyre, fordi en rekke operasjoner måtte utføres for å opprettholde stabelen. B5000 ble designet som en stabelmaskin - alle programdata bortsett fra matriser (som inkluderer strenger og objekter) ble lagret på bunken. Dette betydde at stablingsoperasjoner ble optimalisert for effektivitet. Som en stabelorientert maskin er det ingen programmerbare adresserbare registre.

Multitasking er også veldig effektivt på B5000- og B6500 -linjene. Det er spesifikk instruksjon for å utføre prosessbrytere:

B5000, B5500, B5700
Start P1 (IP1) og Start P2 (IP2)
B6500, B7500 og etterfølgere
MVST (flyttestabel).

Hver bunke og tilhørende programreferansetabell (PRT) representerer en prosess (oppgave eller tråd), og oppgaver kan bli blokkert ved å vente på ressursforespørsler (som inkluderer å vente på at en prosessor skal kjøres hvis oppgaven har blitt avbrutt på grunn av forebyggende multitasking). Brukerprogrammer kan ikke utstede en IP1, IP2 eller MVST, og det er bare ett sted i operativsystemet der dette gjøres.

Så en prosessbryter fortsetter noe slikt - en prosess ber om en ressurs som ikke er umiddelbart tilgjengelig, kanskje en lesning av en fil fra en blokk som ikke er i minnet, eller systemtimeren har utløst et avbrudd. Operativsystemkoden legges inn og kjøres på toppen av brukerbunken. Det slår av tidspunkter for brukerprosesser. Den nåværende prosessen plasseres i riktig kø for ressursen som blir forespurt, eller klar kø som venter på prosessoren hvis dette er en forebyggende kontekstbryter. Operativsystemet bestemmer den første prosessen i den klare køen og påkaller instruksjonen move_stack, som gjør prosessen i spissen for den klare køen aktiv.

Stack hastighet og ytelse

Stackytelse ble ansett som treg sammenlignet med registerbaserte arkitekturer, for eksempel hadde en slik arkitektur blitt vurdert og avvist for System/360 . En måte å øke systemhastigheten på er å holde data så nær prosessoren som mulig. I B5000 -bunken ble dette gjort ved å tilordne de to øverste posisjonene i bunken til to registre A og B. De fleste operasjoner utføres på de to toppen av bunkeposisjonene. På raskere maskiner forbi B5000 kan mer av bunken lagres i registre eller cache i nærheten av prosessoren.

Dermed kan designerne av de nåværende etterfølgerne til B5000 -systemene optimalisere i den siste teknikken, og programmerere trenger ikke å justere koden for at den skal kjøre raskere - de trenger ikke engang å kompilere på nytt og beskytter dermed programvareinvesteringene. Noen programmer har vært kjent for å kjøre i mange år over mange prosessoroppgraderinger. Slik hastighet er begrenset på registerbaserte maskiner.

Et annet punkt for hastighet som fremmet av RISC -designerne var at prosessorhastigheten er betydelig raskere hvis alt er på en enkelt brikke. Det var et gyldig punkt på 1970 -tallet da mer komplekse arkitekturer som B5000 krevde for mange transistorer for å passe på en enkelt brikke. Imidlertid er dette ikke tilfellet i dag, og hver B5000 -etterfølgermaskin passer nå på en enkelt brikke, så vel som ytelsesstøtte teknikker som cacher og instruksjonsrørledninger.

Faktisk inkluderte A-serien av B5000-etterfølgere den første single-chip mainframe, Micro-A på slutten av 1980-tallet. Denne "mainframe" -brikken (kalt SCAMP for Single-Chip A-series Mainframe Processor) satt på et Intel-basert plug-in PC-kort.

Hvordan programmer tilordnes til bunken

Her er et eksempel på hvordan programmer tilordnes stabelen 

begin
   — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
   — This is lexical level 2 (level zero is reserved for the operating system and level 1 for code segments).
   — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
   
   — At level 2 we place global variables for our program.
   
   integer i, j, k;
   real f, g;
   array a [0:9];
   
   procedure p (real p1, p2);
      value p1;     — p1 passed by value, p2 implicitly passed by reference.
      begin
         — — — — — — — — — — — — — — — — — —
         — This block is at lexical level 3
         — — — — — — — — — — — — — — — — — —
         real r1, r2;

         r2 := p1 * 5;
         p2 := r2;  — This sets g to the value of r2
         p1 := r2;  — This sets p1 to r2, but not f
         — Since this overwrites the original value of f in p1 it might be a
         — coding mistake.  Some few of ALGOL's successors therefore insist that
         — value parameters be read only – but most do not.
         
         if r2 > 10 then
            begin
               — — — — — — — — — — — — — — — — — — — — — — — — — — — —
               — A variable declared here makes this lexical level 4
               — — — — — — — — — — — — — — — — — — — — — — — — — — — —
               integer n;

               — The declaration of a variable makes this a block, which will invoke some
               — stack building code. Normally you won't declare variables here, in which
               — case this would be a compound statement, not a block.
               
               ... <== sample stack is executing somewhere here.
            end;
      end;
      
   .....
   
   p (f, g);
end.

Hver stabelramme tilsvarer et leksikalt nivå i det nåværende utførelsesmiljøet. Som du kan se, er leksikalsk nivå den statiske tekstlige hekkingen til et program, ikke den dynamiske samtalen. Synlighetsreglene til ALGOL, et språk designet for enkeltpass -kompilatorer, betyr at bare variabler som er deklarert før den nåværende posisjonen er synlige på den delen av koden, og dermed kravet om fremoverdeklarasjoner. Alle variabler som er deklarert i omsluttende blokker er synlige. Et annet tilfelle er at variabler med samme navn kan deklareres i indre blokker, og disse skjuler effektivt de ytre variablene som blir utilgjengelige.

Leksikalsk hekking er statisk, uten tilknytning til henrettelsesnesting med rekursjon, etc. så det er svært sjelden å finne en prosedyre nestet mer enn fem nivåer dypt, og det kan argumenteres for at slike programmer ville være dårlig strukturert. B5000 -maskiner tillater hekk på opptil 32 nivåer. Dette kan føre til problemer for noen systemer som genererte Algol -kilde som output (skreddersydd for å løse et spesielt problem) hvis generasjonsmetoden ofte nestet prosedyren innenfor prosedyren.

Prosedyrer

Prosedyrer kan påberopes på fire måter - normal, samtale, behandle og kjøre.

Den normale påkallelsen påkaller en prosedyre på den normale måten et hvilket som helst språk påkaller en rutine, ved å suspendere oppringningsrutinen til den påkalte prosedyren kommer tilbake.

Den anropsmekanisme påkaller en prosedyre som en coroutine. Coroutines har partneroppgaver, der kontroll eksplisitt sendes mellom oppgavene ved hjelp av en FORTSETT instruksjon. Dette er synkrone prosesser.

Den prosess mekanisme påkaller en prosedyre som en asynkron oppgave, og i dette tilfelle et separat stabel er satt opp som starter ved den leksikalske nivå av den prosesserte prosedyre. Som en asynkron oppgave er det ingen kontroll over nøyaktig når kontrollen skal sendes mellom oppgavene, i motsetning til coroutines. Den behandlede prosedyren har fortsatt tilgang til det omsluttende miljøet, og dette er en veldig effektiv IPC -mekanisme (Inter Process Communication). Siden to eller flere oppgaver nå har tilgang til vanlige variabler, må oppgavene synkroniseres for å forhindre løpsforhold, som håndteres av EVENT -datatypen, der prosesser kan VENTE på en hendelse til de er forårsaket av en annen samarbeidende prosess. HENDELSER tillater også synkronisering av gjensidig eksklusjon gjennom funksjonene PROCURE og LIBERATE. Hvis underordnet oppgave av en eller annen grunn dør, kan oppringningen fortsette - men hvis den overordnede prosessen dør, avsluttes alle underordnede prosesser automatisk. På en maskin med mer enn én prosessor kan prosessene kjøres samtidig. Denne EVENT -mekanismen er en grunnleggende mulighet for multiprosessering i tillegg til multitasking.

Kjør påkallingstype

Den siste påkallingstypen kjøres . Dette kjører en prosedyre som en uavhengig oppgave som kan fortsette etter at opprinnelsesprosessen er avsluttet. Av denne grunn kan ikke barneprosessen få tilgang til variabler i foreldrenes miljø, og alle parametere som sendes til den påkallede prosedyren må være innkallingsverdi.

Dermed hadde Burroughs Extended ALGOL noen av flerbehandlings- og synkroniseringsfunksjonene til senere språk som Ada . Den benyttet seg av støtten for asynkrone prosesser som var innebygd i maskinvaren.

Inline prosedyrer

En siste mulighet er at en prosedyre kan erklæres INLINE, det vil si når kompilatoren ser en referanse til den, blir koden for prosedyren generert inline for å lagre overheadene til et prosedyreanrop; Dette gjøres best for små biter av kode. Inline -funksjoner ligner parameteriserte makroer som C #defines, bortsett fra at du ikke får problemene med parametere du kan med makroer. Dette anlegget er tilgjengelig i NEWP.

Asynkrone samtaler

I eksempelprogrammet brukes bare normale samtaler, så all informasjon vil være på en enkelt bunke. For asynkrone samtaler vil stabelen bli delt i flere stabler slik at prosessene deler data, men kjøres asynkront.

Vis registre

En stabel maskinvareoptimalisering er levering av D (eller "display") registre. Dette er registre som peker til starten på hver kalt stack -ramme. Disse registrene oppdateres automatisk etter hvert som prosedyrer skrives inn og avsluttes og er ikke tilgjengelige for noen programvare. Det er 32 D -registre, som er det som begrenser til 32 nivåer av leksikalsk hekker.

Vurder hvordan vi får tilgang til en leksikalsk nivå 2 (D [2]) global variabel fra leksikalsk nivå 5 (D [5]). Anta at variabelen er 6 ord fra basen på leksikalsk nivå 2. Den er dermed representert av adresseparet (2, 6). Hvis vi ikke har D -registre, må vi se på kontrollordet ved foten av D [5] -rammen, som peker til rammen som inneholder D [4] -miljøet. Vi ser deretter på kontrollordet i bunnen av dette miljøet for å finne D [3] -miljøet, og fortsetter på denne måten til vi har fulgt alle koblingene tilbake til det nødvendige leksikalske nivået. Dette er ikke den samme banen som returveien tilbake gjennom prosedyrene som har blitt kalt for å komme til dette punktet. (Arkitekturen holder både datastakken og samtalestakken i samme struktur, men bruker kontrollord for å skille dem fra hverandre.)

Som du kan se, er dette ganske ineffektivt bare for å få tilgang til en variabel. Med D -registre peker D [2] -registeret ved basen av det leksikale nivå 2 -miljøet, og alt vi trenger å gjøre for å generere adressen til variabelen er å legge til dens forskyvning fra bunkerammebasen til rammebaseadressen i D -registeret. (Det er en effektiv koblet liste -søkoperatør LLLU, som kan søke i stabelen på ovennevnte måte, men D -registertilnærmingen kommer fortsatt til å være raskere.) Med D -registre er tilgang til enheter i ytre og globale miljøer like effektiv som lokal variabel tilgang. 

D Tag Data                — Address couple, Comments
register

| 0        | n          | (4, 1) The integer n (declared on entry to a block, not a procedure)
|-----------------------|
| D[4]==>3 | MSCW       | (4, 0) The Mark Stack Control Word containing the link to D[3].
|=======================|
| 0        | r2         | (3, 5) The real r2
|-----------------------|
| 0        | r1         | (3, 4) The real r1
|-----------------------|
| 1        | p2         | (3, 3) A SIRW reference to g at (2,6)
|-----------------------|
| 0        | p1         | (3, 2) The parameter p1 from value of f 
|-----------------------|
| 3        | RCW        | (3, 1) A return control word
|-----------------------|
| D[3]==>3 | MSCW       | (3, 0) The Mark Stack Control Word containing the link to D[2].
|=======================|
| 1        | a          | (2, 7) The array a  ======>[ten word memory block]
|-----------------------|
| 0        | g          | (2, 6) The real g 
|-----------------------|
| 0        | f          | (2, 5) The real f 
|-----------------------|
| 0        | k          | (2, 4) The integer k 
|-----------------------|
| 0        | j          | (2, 3) The integer j 
|-----------------------|
| 0        | i          | (2, 2) The integer i
|-----------------------|
| 3        | RCW        | (2, 1) A return control word
|-----------------------|
| D[2]==>3 | MSCW       | (2, 0) The Mark Stack Control Word containing the link to the previous stack frame.
|=======================| — Stack bottom

Hvis vi hadde påberopt prosedyren p som en coroutine, eller en prosessinstruksjon, hadde D [3] -miljøet blitt en egen D [3] -basert stabel. Dette betyr at asynkrone prosesser fremdeles har tilgang til D [2] -miljøet som antydet i ALGOL -programkoden. Hvis du tar dette et skritt videre, kan et helt annet program kalle et annet programs kode, og skape en D [3] stabelramme som peker til en annen prosess 'D [2] miljø på toppen av sin egen prosessbunke. På et øyeblikk endres hele adresserommet fra kodeens utførelsesmiljø, noe som gjør D [2] -miljøet på egen prosessbunke ikke direkte adresserbart og i stedet gjør D [2] -miljøet i en annen prosessbunke direkte adresserbart. Slik implementeres bibliotekssamtaler. Ved et slikt cross-stack-anrop kan telefonkoden og den ringte koden til og med stamme fra programmer skrevet på forskjellige kildespråk og bli samlet av forskjellige kompilatorer.

D [1] og D [0] miljøene forekommer ikke i den nåværende prosessens stabel. D [1] -miljøet er kodesegmentordboken, som deles av alle prosesser som kjører den samme koden. D [0] -miljøet representerer enheter som eksporteres av operativsystemet.

Stabelrammer trenger faktisk ikke engang eksistere i en prosessbunke. Denne funksjonen ble brukt tidlig for fil -I/O -optimalisering, FIB (filinformasjonsblokk) ble koblet til displayregistrene ved D [1] under I/O -operasjoner. På begynnelsen av nittitallet ble denne evnen implementert som en språkfunksjon som STRUKTURBLokker og - kombinert med biblioteksteknologi - som TILKOBLINGSBLokker. Evnen til å koble en datastruktur til displayets registeradresseomfang implementert objektorientering. Dermed brukte B5000 faktisk en form for objektorientering lenge før begrepet noen gang ble brukt.

På andre systemer kan kompilatoren bygge sin symboltabell på en lignende måte, men til slutt vil lagringskravene bli samlet og maskinkoden vil bli skrevet for å bruke flate minneadresser på 16-bits eller 32-bits eller til og med 64-bits. Disse adressene kan inneholde alt slik at et skrive til feil adresse kan skade noe. I stedet ble den todelte adresseplanen implementert av maskinvaren. På hvert leksikalsk nivå ble variabler plassert på forskyvninger opp fra bunnen av nivåets bunke, og opptar vanligvis ett ord - dobbel presisjon eller komplekse variabler ville oppta to. Matriser ble ikke lagret i dette området, bare en ordbeskrivelse for matrisen var. Dermed var det totale lagringskravet på hvert leksikalsk nivå ikke stort: ​​dusinvis, hundrevis eller noen få tusen i ekstreme tilfeller, absolutt ikke en telling som krever 32-bits eller mer. Og faktisk gjenspeiles dette i form av VALC -instruksjonen (verdiskall) som lastet en operand på stabelen. Denne op-koden var to biter lang og resten av bytes biter ble sammenkoplet med følgende byte for å gi et fjorten-bits adresseringsfelt. Koden som blir utført, ville være på et leksikalt nivå, si seks: dette betydde at bare leksikalske nivåer null til seks var gyldige, og derfor var det bare tre biter som trengs for å spesifisere det leksikale nivået som ønsket. Adressedelen av VALC -operasjonen reserverte dermed bare tre biter til dette formålet, med resten tilgjengelig for henvisning til enheter på det og lavere nivåer. En dypt nestet prosedyre (altså på et høyt leksikalsk nivå) ville ha færre biter tilgjengelig for å identifisere enheter: for nivå seksten og oppover ville det være nødvendig med fem biter for å spesifisere valget av nivåene 0–31 og dermed la ni biter stå for å identifisere ikke mer enn den første 512 enheter på et hvilket som helst leksikalsk nivå. Dette er mye mer kompakt enn å adressere enheter etter sin bokstavelige minneadresse i et 32-biters adresserom. Videre var det bare VALC -kode som lastet inn data: opkoder for ADD, MULT og så videre adresserte ikke, og jobbet helt på de øverste elementene i stabelen.

Mye viktigere er at denne metoden betydde at mange feil tilgjengelig for systemer som bruker flat adressering ikke kunne oppstå fordi de rett og slett var usigelige selv på maskinkodenivå. En oppgave hadde ingen måte å ødelegge minne ved bruk av en annen oppgave, fordi den ikke hadde mulighet til å utvikle adressen. Forskyvninger fra et spesifisert D-register vil bli kontrollert av maskinvaren mot stabelrammen som er bundet: useriøse verdier ville bli fanget. På samme måte inneholdt en matrisbeskrivelse i en oppgave informasjon om matrisens grenser, og derfor ble enhver indekseringsoperasjon kontrollert av maskinvaren: på en annen måte dannet hver matrise sitt eget adresserom. Uansett ga merkingen av alle minneord et annet beskyttelsesnivå: en feildirigert tildeling av en verdi kan bare gå til et datalagringssted, ikke til et som holder en peker eller en matrisebeskrivelse, etc. og absolutt ikke til en plassering som inneholder maskinkode.

Array lagring

Arrays ble ikke lagret sammenhengende i minnet med andre variabler, de fikk hver sitt adresserom, som ble lokalisert via deskriptoren. Tilgangsmekanismen skulle beregne indeksvariabelen (som derfor hadde hele heltallspotensialet, ikke bare fjorten biter) på stakken og bruke den som forskyvning i matrisens adresserom, med begrenset kontroll levert av maskinvaren. Skulle lengden på en matrise overstige 1024 ord, ville matrisen bli segmentert og indeksen konvertert til en segmentindeks og en forskyvning til det indekserte segmentet. I ALGOLs tilfelle vil en flerdimensjonal matrise bruke flere nivåer av slik adressering. For en referanse til A (i, j), vil den første indeksen være i en rekke deskriptorer, en deskriptor for hver av radene i A, hvilken rad vil så bli indeksert med j som for en endimensjonal matrise, og så på for høyere dimensjoner. Maskinvarekontroll mot de kjente grensene for alle matrisens indekser ville forhindre feilaktig indeksering.

FORTRAN anser imidlertid alle flerdimensjonale matriser for å være ekvivalente med en endimensjonal matrise av samme størrelse, og for en flerdimensjonal matrise brukes enkelt heltalls aritmetikk for å beregne forskyvningen der element A (i, j, k) vil bli funnet i denne singelen sekvens. Det endimensjonale ekvivalente arrayet, muligens segmentert hvis det er stort nok, ville da bli åpnet på samme måte som et endimensjonalt array i ALGOL. Selv om tilgang utenfor denne matrisen ville bli forhindret, kan det være at en feil verdi for en indeks kombinert med en passende feil verdi for en annen indeks ikke resulterer i grenseverdier for enkeltsekvensmatrisen; indeksene ble med andre ord ikke sjekket individuelt.

Fordi en matrises lagring ikke var begrenset på hver side av lagring for andre elementer, var det enkelt for systemet å "endre størrelse" på en matrise - selv om endring av antall dimensjoner var utelukket fordi kompilatorer krevde at alle referanser hadde samme antall dimensjoner. I ALGOLs tilfelle muliggjorde dette utviklingen av "filete" matriser, i stedet for de vanlige faste rektangulære (eller høyere dimensjoner) matriser. I to dimensjoner ville en filet rekke ha rader av forskjellige størrelser. For eksempel, gitt et stort utvalg A (100,100) med stort sett nullverdier, kan en sparsom matrisepresentasjon som ble erklært som SA (100,0) få størrelsen på hver rad til å ha nøyaktig nok elementer til å bare inneholde ikke-nullverdiene til A langs den rekken.

Fordi matriser større enn 1024 ord ble segmentert, men mindre matriser ikke, på et system som manglet reelt minne, kan en økning av den deklarerte størrelsen på en samling skrapelegger fra 1000 til si 1050 bety at programmet ville kjøre med langt mindre " thrashing "ettersom bare de mindre individuelle segmentene i bruk var nødvendig i minnet. Faktisk lagring for et matrisegment ville bare blitt tildelt ved kjøretid hvis et element i det segmentet ble åpnet, og alle elementene i et opprettet segment ville bli initialisert til null. Å ikke initialisere en matrise til null i starten ble derfor oppmuntret av dette, normalt en uklok unnlatelse.

Stack struktur fordeler

En fin ting med stakkstrukturen er at hvis et program tilfeldigvis mislykkes, blir det tatt en stabeldump, og det er veldig enkelt for en programmerer å finne ut nøyaktig hva tilstanden til et program som kjører var. Sammenlign det med kjernedumper og utvekslingspakker med andre systemer.

En annen ting med stabelen er at programmene implisitt er rekursive. FORTRAN var ikke forventet å støtte rekursjon og kanskje en snublestein for folks forståelse av hvordan ALGOL skulle implementeres var hvordan man implementerer rekursjon. På B5000 var dette ikke et problem - faktisk hadde de det motsatte problemet, hvordan de kunne stoppe programmer fra å være rekursive. Til slutt gadd de ikke. Burroughs FORTRAN-kompilatoren tillot rekursive anrop (akkurat som alle andre FORTRAN-kompilatorer gjør), men i motsetning til mange andre datamaskiner lyktes også returene fra slike samtaler på et stabelbasert system. Dette kan ha merkelige effekter, som med et system for formell manipulering av matematiske uttrykk hvis sentrale subrutiner gjentatte ganger påkalte hverandre uten å komme tilbake: store jobber ble avsluttet med stabeloverløp!

Dermed hadde Burroughs FORTRAN bedre feilkontroll enn annen moderne implementering av FORTRAN. For eksempel for subrutiner og funksjoner sjekket det at de ble påkalt med riktig antall parametere, slik det er normalt for kompilatorer i ALGOL-stil. På andre datamaskiner var slike feilpasninger vanlige årsaker til krasj. På samme måte med den matrisebundne kontrollen: programmer som hadde blitt brukt i mange år på andre systemer, ville pinlig ofte mislykkes når de kjøres på et Burroughs-system. Faktisk ble Burroughs kjent for sine overlegne kompilatorer og implementering av språk, inkludert den objektorienterte Simula (et supersett av ALGOL), og Iverson , designeren av APL erklærte at Burroughs-implementeringen av APL var det beste han hadde sett. John McCarthy , språkdesigneren til LISP var uenig, siden LISP var basert på modifiserbar kode, likte han ikke den umodifiserbare koden til B5000, men de fleste LISP -implementeringene ville kjøre i et tolkningsmiljø uansett.

Lagringen som kreves for flere prosesser kom fra systemets minnebasseng etter behov. Det var ikke nødvendig å gjøre SYSGEN -er på Burroughs -systemer som med konkurrerende systemer for å forhåndskonfigurere minnepartisjoner for å kjøre oppgaver.

Merket arkitektur

Det mest definerende aspektet ved B5000 er at det er en stabelmaskin som behandlet ovenfor. To andre veldig viktige trekk ved arkitekturen er imidlertid at den er tag-basert og deskriptorbasert.

I den opprinnelige B5000 ble en flaggbit i hvert kontroll- eller tallord satt til side for å identifisere ordet som et kontrollord eller et numerisk ord. Dette var delvis en sikkerhetsmekanisme for å stoppe programmer fra å kunne ødelegge kontrollord på stabelen.

Senere, da B6500 ble designet, ble det innsett at 1-biters kontrollord/numerisk skille var en kraftfull idé, og dette ble utvidet til tre biter utenfor 48-bitsordet til en tag. Databitene er bits 0–47 og taggen er i bits 48–50. Bit 48 var skrivebeskyttet, og derfor merket merkelige tagger kontrollord som ikke kunne skrives av et brukernivåprogram. Kodeord ble gitt tag 3. Her er en liste over taggene og deres funksjon:

stikkord Ord slag Beskrivelse
0 Data Alle typer bruker- og systemdata (tekstdata og enkle presisjonsnumre)
2 Dobbelt Dobbel presisjonsdata
4 SIW Trinnindeksord (brukt i sløyfer)
6 Uinitialiserte data
SCW Software Control Word (brukes til å kutte stabelen)
1 IRW Indirekte referanseord
SIRW Fylt indirekte referanseord
3 Kode Program kodeord
MSCW Merk Stack Control Control Word
RCW Returner kontrollord
TOSCW Toppen av Stack Control Word
SD Segmentbeskrivelse
5 Beskrivelse Datablokkbeskrivere
7 PCW Programkontrollord

Internt hadde noen av maskinene 60 biters ord, med de ekstra bitene som ble brukt til ingeniørformål, for eksempel et Hamming -kodefeilkorrigeringsfelt, men disse ble aldri sett av programmerere.

Den nåværende inkarnasjonen av disse maskinene, Unisys ClearPath, har utvidet koder ytterligere til en firebitskode. Mikrokodenivået som spesifiserte fire biters tagger ble referert til som nivå Gamma.

Jevnt merkede ord er brukerdata som kan endres av et brukerprogram som brukerstatus. Odd-tagged ord opprettes og brukes direkte av maskinvaren og representerer et programs utførelse. Siden disse ordene er opprettet og konsumert av spesifikke instruksjoner eller maskinvaren, trenger det nøyaktige formatet til disse ordene ikke endres mellom maskinvareimplementering og brukerprogrammer, siden den samme kodestrømmen vil gi de samme resultatene, selv om systemord formatet kan ha endret seg.

Tag 1 ord representerer on-stack data adresser. Den normale IRW lagrer ganske enkelt et adressepar til data på gjeldende stabel. SIRW refererer til data på en hvilken som helst stabel ved å inkludere et stabelnummer i adressen.

Tag 5 -ord er deskriptorer, som er mer fullstendig beskrevet i neste avsnitt. Merk 5 ord representerer off-stack data adresser.

Tag 7 er programkontrollordet som beskriver et inngangspunkt for en prosedyre. Når operatører treffer en PCW, blir prosedyren angitt. ENTR-operatøren går eksplisitt inn i en prosedyre (rutine som ikke returnerer verdi). Funksjoner (verdi-returnerende rutiner) er implisitt angitt av operatører, for eksempel value call (VALC). Globale rutiner lagres i D [2] -miljøet som SIRW -er som peker til en PCW som er lagret i kodesegmentordlisten i D [1] -miljøet. D [1] -miljøet er ikke lagret på gjeldende stabel fordi det kan refereres til av alle prosesser som deler denne koden. Dermed blir koden reentrant og delt.

Tag 3 representerer selve kodeordene, som ikke vil forekomme på bunken. Tag 3 brukes også for stabelkontrollordene MSCW, RCW, TOSCW.

Figur 9.2 Fra ACM -monografien i referansene. Elliot Organick 1973.

Beskrivelsesbasert arkitektur

Figuren til venstre viser hvordan Burroughs Large System-arkitekturen i utgangspunktet var en maskinvarearkitektur for objektorientert programmering , noe som fremdeles ikke eksisterer i konvensjonelle arkitekturer.

Hovedartikkel: Burroughs store systembeskrivere

Instruksjonssett

Det er tre forskjellige instruksjonssett for Burroughs store systemer. Alle tre er basert på korte stavelser som passer jevnt i ord.

B5000, B5500 og B5700

Hovedartikkel: B5000 Instruksjonssett

Programmer på en B5000, B5500 og B5700 består av 12-bits stavelser , fire til et ord. Arkitekturen har to moduser, Word Mode og Character Mode, og hver har et eget repertoar med stavelser. En prosessor kan enten være kontrolltilstand eller normal tilstand, og visse stavelser er bare tillatt i kontrolltilstand. Arkitekturen gir ikke mulighet til å adressere registre eller lagring direkte; alle referanser er gjennom 1024 ords programreferansetabell, nåværende kodesegment, merkede steder i bunken eller til A- og B -registerene som holder de to øverste stedene på bunken. Burroughs tallbiter i en stavelse fra 0 (høy bit) til 11 (lav bit)

B6500, B7500 og etterfølgere

Hovedartikkel: Burroughs B6x00-7x00 instruksjonssett

Programmene består av 8-biters stavelser , som kan være Name Call, være Value Call eller danne en operator, som kan være fra en til tolv stavelser i lengde. Det er mindre enn 200 operatører , som alle passer inn i 8-bits stavelser. Mange av disse operatørene er polymorfe avhengig av typen data som blir handlet på som gitt av taggen. Hvis vi ignorerer de kraftige strengskannings-, overførings- og redigeringsoperatørene, er det grunnleggende settet bare omtrent 120 operatører. Hvis vi fjerner operatørene som er reservert for operativsystemet, for eksempel MVST og HALT, er settet med operatører som vanligvis brukes på programmer på brukernivå mindre enn 100. Stavelsene Navneanrop og Verdiskall inneholder adressepar ; Operatørstavelsene bruker enten ingen adresser eller bruker kontrollord og deskriptorer på bunken.

Flere prosessorer

B5000-linjen var også pionerer i å ha flere prosessorer koblet sammen på en høyhastighetsbuss. B7000 -linjen kan ha opptil åtte prosessorer, så lenge minst en var en I/O -modul. RDLK er en veldig lav måte å synkronisere mellom prosessorer. Det høye nivået som brukes av brukerprogrammer er EVENT -datatypen. EVENT -datatypen hadde en viss systemkostnad. For å unngå denne overhead kan en spesiell låsteknikk kalt Dahm locks (oppkalt etter en Burroughs programvareguru, Dave Dahm) brukes.

Viktige operatører er:

HEYU -send et avbrudd til en annen prosessor
RDLK -Lavt nivå semaforoperatør : Last inn A-registeret med minneplassering gitt av A-registeret og plasser verdien i B-registret på det minnestedet i en enkelt avbruddsfri syklus. Algol-kompilatoren produserte kode for å påkalle denne operatøren via en spesiell funksjon som muliggjorde en "bytte" -operasjon på enkeltorddata uten en eksplisitt midlertidig verdi. x:=RDLK(x,y);
WHOI - prosessoridentifikasjon
IDLE - inaktiv til et avbrudd mottas

To prosessorer kan sjelden samtidig sende en HEYU -kommando til hverandre, noe som resulterer i en lockup kjent som 'en dødelig omfavnelse '.

Påvirkning av B5000

Den direkte innflytelsen fra B5000 kan sees i dagens Unisys ClearPath -serie med hovedrammer, som er direkte etterkommere av B5000 og fortsatt har MCP -operativsystemet etter 40 års konsekvent utvikling. Denne arkitekturen kalles nå emode (for emuleringsmodus) siden B5000 -arkitekturen er implementert på maskiner bygget fra Intel Xeon -prosessorer som kjører x86 -instruksjonssettet som det opprinnelige instruksjonssettet, med kode som kjører på de prosessorene som etterligner B5000 -instruksjonssettet. I disse maskinene skulle det også være en nmode ( innfødt modus ), men dette ble droppet, så du kan ofte høre B5000 -etterfølgermaskinene bli referert til som "emodemaskiner".

B5000-maskiner ble utelukkende programmert på språk på høyt nivå; det er ingen montør.

B5000 -stakkarkitekturen inspirerte Chuck Moore , designeren av programmeringsspråket Forth , som møtte B5500 mens han var på MIT. In Forth - The Early Years beskrev Moore innflytelsen, og bemerket at Forths DUP, DROP og SWAP kom fra de tilsvarende B5500 -instruksjonene (DUPL, DLET, EXCH).

B5000-maskiner med sin stabelbaserte arkitektur og merkede minne påvirket også den sovjetiske Elbrus- serien med hovedrammer og superdatamaskiner sterkt . De to første generasjonene av serien inneholdt merket minne og stabelbaserte CPUer som bare var programmert på språk på høyt nivå. Det eksisterte et slags samlingsspråk for dem, kalt El-76, men det var mer eller mindre en modifikasjon av ALGOL 68 og støttet strukturert programmering og førsteklasses prosedyrer. Senere generasjoner av serien byttet imidlertid vekk fra denne arkitekturen til EPIC -lignende VLIW -prosessorer .

De Hewlett-Packard designere av HP 3000 forretningssystemet hadde brukt en B5500 og var sterkt imponert av sin maskinvare og programvare; de hadde som mål å bygge en 16-biters minidatamaskin med lignende programvare. Flere andre HP -divisjoner opprettet lignende minidatamaskiner eller mikroprosessorbunker. Bob Bartons arbeid med omvendt polsk notasjon (RPN) fant også veien inn i HP-kalkulatorer som begynte med 9100A, og spesielt HP-35 og påfølgende kalkulatorer.

NonStop-systemene designet av Tandem Computers på slutten av 1970-tallet og begynnelsen av 1980-tallet var også 16-biters stabelmaskiner, påvirket av B5000 indirekte gjennom HP 3000-tilkoblingen, ettersom flere av de tidlige Tandem-ingeniørene tidligere var hos HP. Rundt 1990 migrerte disse systemene til MIPS RISC -arkitekturen, men fortsatte å støtte utførelse av bunkefiler med bunkemaskiner ved oversettelse av objektkode eller direkte emulering. En gang etter 2000 migrerte disse systemene til Itanium -arkitektur og fortsatte å kjøre de eldre stabelmaskinbinariene.

Bob Barton var også veldig innflytelsesrik på Alan Kay . Kay var også imponert over den datadrevne merkede arkitekturen til B5000, og dette påvirket tankegangen hans i utviklingen innen objektorientert programmering og Smalltalk .

En annen fasett ved B5000 -arkitekturen var at det var en sikker arkitektur som kjører direkte på maskinvare. Denne teknikken har etterkommere i dagens virtuelle maskiner i deres forsøk på å tilby sikre miljøer. Et bemerkelsesverdig slikt produkt er Java JVM som gir en sikker sandkasse der applikasjoner kjøres.

Verdien av maskinvarearkitekturbindingen som eksisterte før emoden ville i det vesentlige blitt bevart i de x86 -baserte maskinene i den grad MCP var det eneste kontrollprogrammet, men støtten fra disse maskinene er fremdeles dårligere enn den som tilbys på maskiner der B5000 instruksjonssett er det opprinnelige instruksjonssettet. En lite kjent Intel-prosessorarkitektur som faktisk gikk foran 32-biters implementeringer av x86-instruksjonssettet, Intel iAPX 432 , ville ha gitt et tilsvarende fysisk grunnlag, ettersom det også egentlig var en objektorientert arkitektur.

Se også

Merknader

Referanser

  • The Extended ALGOL Primer (Three Volumes), Donald J. Gregory.
  • Dataarkitektur: En strukturert tilnærming, R. Doran, Academic Press (1979).
  • Stack Computers: The New Wave, Philip J. Koopman, tilgjengelig på: [1]
  • B5500, B6500, B6700, B6800, B6900, B7700 manualer på: bitsavers.org

Videre lesning

Eksterne linker