Zoals bekend bestaat 90% van de wereldbevolking uit kruideniers. Omdat onder programmeurs het percentage ten minste zo hoog is, leid ik de overige sprekers in.
Het is mijn ervaring dat de overgrote meerderheid der programmeurs, systeembouwers en zelfs machinebouwers hun werk in eerste instantie beschouwen als een optimaliseringsopgave, nl. de minimalisering van wat ze de "cost/performance ratio" noemen. Wij hebben geweigerd—of, zo U wilt, ik heb geweigerd en mijn medewerkers zijn mij hierin bijgevallen—om aan dit efficiencystreven het primaat te geven en wij hebben het multiprogrammeringsproject in eerste instantie beschouwd als intellectuele uitdaging: hoe kan je zorgen dat in een dergelijk systeem de complexiteit je niet boven het hoofd groeit, hoe kan je zorgen dat je het ontwerp- en constructieproces blijft beheersen. Slechts binnen de speelruimte, die ons hierdoor gelaten werd hebben wij efficiencyoverwegingen ons doen en laten laten beïnvloeden.
Ik heb ervaren dat geschilderde relativering van de efficiency eis voor hen, die van efficiency hun heilig ideaal gemaakt hebben, niets meer of minder dan heiligschennis is. Ik ben dan ook bejegend als de rebel, die zich niet aan de spelregels gehouden heeft. Wanneer na afloop blijkt, dat wij in weerwil van de veronachtzaming waarvan we beschuldigd werden, een systeem geschapen hebben, waarvan de "performance figures" in dezelfde orde van grootte liggen, dan is de boot helemaal aan. Voor kruideniers is dit natuurlijk ook heel frustrerend en het ontlokt allerlei verzetsreacties tot bijna onverbloemde verdachtmakingen toe.
Maar ik vraag U een pas terug te doen. Lange tijd hebben rekenautomaten alleen fixed point arithmetiek ingebouwd gehad, niet alleen omdat floating point arithmetiek moeilijker te bouwen was, maar ook omdat John von Neumann ervan overtuigd was, dat je floating point arithmetiek niet nodig had, je kon je probleem best schalen. Desalnietemin zijn software makers met veronachtzaming van enige efficiency eisen floating point arithmetiek gaan implementeren en nu zijn we blij, dat dit in de hardware zit. Je zou in een moment van optimisme kunnen denken, dat de mensheid van die ervaring geleerd zou hebben, maar niets daarvan. Een aantal jaren later bij de opkomst van de programmeertalen, werd er weer moord en brand geschreeuwd, nl. door die programmeurs die in een gewiekste exploitatie van een speciale machine code hun hoogste goed zagen. En ettelijken zijn daarin blijven steken. En nu heb je de volgende generatie moord-en-brand-schreeuwers, nl. de programmeurs die de exploitatie van een specifieke configuratie als hun hoogste taak zien. Het wordt eentonig.
Maar het is duidelijk dat men de kunst van het programmeren, de kunst van het machinegebruik alleen dan verder kan helpen, wanneer men, zo daar goede gronden voor aanwezig zijn, bereid is de platgetreden paden te verlaten. En hierin ligt een van de redenen, waarom ik aan efficiency overwegingen niet het primaat wil geven: dat is nl. zo verlammend. Ik wil ze wel in het oog houden, maar dat is heel iets anders. En er waren ditmaal goede gronden. Toen we er aan begonnen, zijn we nog voor gek versleten—schriftelijk zelfs, maar ik zal de firma die dat gedaan heeft, niet noemen. U mag één keer raden—de ontwikkeling heeft aangetoond dat er in de rest van de wereld (laten we het voorzichtig uitdrukken) meer van zulke gekken te vinden waren.
Nu over het project zelf. Ik heb de EL X8, waarvoor we dit gedaan hebben, nooit beschouwd als speciaal voor multiprogrammering ontworpen, eer als inspirerende machine om het mee te proberen. Ik noem in dit verband speciaal de interrupt hardware, waarop je op logische gronden verliefd kunt worden. Ik wil hier graag met nadruk verklaren dat het entameren van het multiprogrammeringsproject onverantwoord zou zijn geweest, als wij niet met zekerheid hadden kunnen aannemen dat we, in geval het niet zou lukken, de software van het MC achter de hand zouden hebben om hier het Rekencentrum te bedrijven. Zonder dat vertrouwen hadden wij ons nooit kunnen permitteren dit stukje "Hogeschool programmering" weg te geven. Ik wil graag aan de vergetelheid onttrekken dat het tot begin 1967 geduurd heeft, voordat wij er vertrouwen in begonnen te krijgen, dat we een werkend "workable" systeem zouden produceren. En zelfs sindsdien heeft dat vertrouwen nog wel eens gewankeld. Je vergeet dit zo gauw, maar we zijn heel vaak heel bang geweest.
Wie een multiprogrammeersysteem ontwerpt, loopt onmiddellijk tegen de toewijzingsproblemen aan. Je kunt het je in dezen makkelijk maken en royaal met vaste toewijzingen werken, je kunt moeilijk maken en zoveel mogelijk dynamisch uitwisselbaar houden. Wij zijn in de laatste richting vrij ver gegaan en hebben ons over dit beoogde raffinement allerlei ellende op de hals gehaald. Voor kenners noem ik de bankiersalgorithme als notoir voorbeeld; voorts noem ik de bereidheid van het systeem om de geheugenruimte, die normaal voor transportbuffering ter beschikking staat, dynamisch in te krimpen als meer ruimte voor de programmaverwerking nodig blijkt. Tilt men niet zo zwaar aan dit raffinement, dan kan men een goed stuk van het systeem beschouwen als "self inflicted pain". In antwoord hierop zou ik, zonder nu mijzelf als masochist te willen presenteren, willen zeggen "Daar ging het ons in zekere zin om." Wij zijn geen lustprogrammeurs in de zin, dat we het ons liever moeilijk dan makkelijk hebben gemaakt. Integendeel, elke complicerende factor moest een aanwijsbaar doel dienen, voordat hij werd toegelaten en in het ontwerpstadium hebben we ook ettelijke er weer uitgepraat. Het ging ons wel om een opgave die alle mogelijkheid in zich borg om ondoenlijk moeilijk te worden om dan te ontdekken hoe men vervolgens het werk zo makkelijk kan houden dat men het tot een goed einde brengen kan.
Het multiprogrammeringssysteem is met een dubbel doel ontwikkeld. Ten eerste wilden we voor kleine programmaatjes de turn-around time verkorten. Van batch-processing systemen was ons bekend, dat de turn-around time vaak in de uren ging lopen, ook al vergde het programmaatje maar enkele minuten rekentijd. Aangezien wij door de studentenbevolking vele kleine programmaatjes verwachten vonden we dit onaantrekkelijk. Een multiprogrammeringssysteem, waarin een langdurig programma de machine niet blokkeert, schept een van de voorwaarden om de turn-around time voor kleintjes veel kleiner te laten zijn.
Ten tweede wilden we de mogelijkheid tot enkele gebruiksvormen scheppen, die zonder multiprogrammering zouden afketsen op te inefficiënte benutting van het rekenorgaan. We wilden de programmeur ontlasten van de plicht rekening te houden met de tweeslachtigheid van het geheugen: het systeem verzorgt automatisch de noodzakelijke transporten tussen langzaam en snel geheugen als het snelle geheugen te klein blijkt. Dit geschiedt volgens "demand pageing", dus, informatie wordt pas uit het langzame geheugen voorgaats gehaald als het verwerkende proces er aan toe is en de informatie op dat moment niet in de kernen aanwezig is. Gedurende het dan volgende transport kan het verwerkende proces niet verder! Multiprogrammering is een methode om gedurende die transporttijd nochtans emplooi voor het rekenorgaan te vinden. Vervolgens wilden we de machine kunnen gebruiken voor processen, die qualitate qua slechts op een fractie van de tijd van het rekenorgaan beslag leggen. Wij noemen in dit verband de extra bandlezer en bandponser, waarmee men "in een hoekje van de machine" banden dan copiëren, corrigeren etc. en de tweede teleprinter die voor experimenteel conversationeel werk bestemd is, en een dezer weken in het systeem zal worden opgenomen. De derde toepassing, waarmee we rekening willen houden was online koppeling met meet-apparatuur. Dit laatste is nog niet gerealiseerd, in de enkele gevallen, dat er sprake van is geweest bleken de hieraan verbonden verplichtingen kwantitatief gezien prohibitief te zijn.
Wat wij niet hebben wilen maken was een multi-access systeem dat consoles alom bedient. Dat was één à twee jaar geleden "le dernier cri" maar ik houd er ernstig rekening mee dat dit in zijn huidige vorm een modegril van voorbijgaande aard zal blijken. Ik, voor mij, zou de installatie van een dergelijk systeem ook niet durven aanbevelen voordat mij een verantwoorde wijze van gebruik voor ogen stond. Maar zoiets hebben we met dit systeem ten duidelijkste dus niet geprobeerd.
Rest mij slechts U te danken voor Uw aanwezigheid en Uw belangstelling en het woord te geven aan de volgende sprekers.