Herinneringen van oud-Electrologica-medewerkers

Ik kwam een verhaal van een hardware-man tegen. Dat kan hier  gevonden worden.

Het verhaal inspirereerde mij om ook eens wat herinneringen op papier te zetten.

Het begin

Ik kwam als bijna 20-jarige op 1 mei 1966 bij Electrologica terecht. Ik kwam daar omdat EL grootse plannen had en veel personeel aan het werven was, vnml. gesjeesde studenten e.d.

Ik had mijn middelbare school niet afgemaakt maar ik had wel programmeerervaring: anderhalf jaar assemblerprogrammering voor een IBM 1401-systeem. Daarom was ik aantrekkelijk voor EL.

Ik kwam op een grote kamer met voornamelijk mensen die een maand eerder in dienst getreden waren.

We kregen een uitgebreide opleiding. Ik eerst individueel omdat ik een maand achterliep maar al snel met z'n allen: ELAN-programmering voor de EL-X8 en Algol.

Het aantrekkelijke was ook dat ik voor het eerst alleen ging wonen. Ik had via EL een kleine kamer kunnen huren maar die was wel helemaal van mijzelf. En ik kon doen en laten wat ik wilde.
Er waren onder de nieuwe aanwas wel meer die speciaal naar de Haagse regio waren gekomen. We deden ook wel dingen samen. Ik herinner me nog Sinterklaasfeesten bij collega's op hun kamer.

De eerste echte opdracht die we kregen was het schrijven van testprogramma's voor de symbolenbox. Er waren een aantal Amerikanen ingehuurd om een Cobol-compiler te maken voor de EL-X8. Die had geen decimale instructies dus die moesten gesimuleerd worden.

Een andere opdracht was het maken van programmatuur om binaire programmabestanden van ponskaarten in te kunnen lezen voor de EL-X2, een uitgeklede versie van de EL-X8.

Een probleem was dat je niet zo maar binaire informatie in een ponskaart kon stoppen op een efficiënte manier. Als je een 1 door een gaatje liet representeren zou je kaarten kunnen krijgen met wel erg veel gaatjes. Niet goed voor de ponsmachine en niet goed voor de ponskaart. Dus had iemand een codering bedacht waarmee je met hoogstens 2 gaatjes per kolom toch binaire informatie in die kolom kon stoppen. Hoe het precies zat weet ik niet meer maar je kunt met 2 gaatjes 66 verschillende combinaties bedenken. En daarmee kun je dan 6 bits representeren. Je hebt dan 5 kolommen nodig voor één EL-X8-woord van 27 bits. Dus 16 woorden per kaart. Zoiets zal het wel geweest zijn.

Testen deden we zelf op de meest ongelukkige momenten op machines die nog in de testruimte van het produktiedeel stonden. Soms kregen we 's ochtends om 6 uur testtijd en dat deden we dan. De vergoeding voor overwerk was een welkome aanvulling op het niet al te ruime salaris.

Drivers voor het Algol-systeem

Daarna kwam ik bij de Algol-groep terecht. Niet dat ik aan de compiler ging werken (die was gemaakt door het Mathematisch Centrum, de bakermat van de voorganger van de EL-X8, de EL-X1) maar aan de picotor, het OS voor het Algol-systeem.

Mijn eerste opdracht was een driver te maken voor een ander type regeldrukker dan we al hadden.

Dat hield in dat ik me ook moest verdiepen in de werking van I/O-opdrachten. Allemaal spannend!

De regeldrukker kende alleen maar hoofdletters maar ik moest ook het onderscheid kunnen maken tussen hoofdletters en kleine letters en bovendien moesten ook onderstrepingen weergegeven kunnen worden. Bijv. voor het afdrukken van Algol-programma's waar constructies als Boolean mogelijk zijn als alternatief voor boolean. Tenslotte is de boolean genoemd naar meneer Boole.

De oplossing die gekozen was, was om door hoofdletters een ' te drukken en evt. een losse onderstreping. Dat hield in dat je eerst de te printen regel moest onderzoeken en, als er hoofdletters en onderstrepingen in zaten, de tekst zonder linefeed af te drukken gevolgd door nog een tweede en evt. derde regel met ' en _.

Ik heb ook nog een driver gemaakt voor de PRD, een kaartlezer/kaartponser. Een omgebouwde ponskaartenreproducer van Bull. Een vreselijk apparaat wat voornamelijk mechanisch was.

Er zaten twee complicaties bij die ik me nog herinner:

  • voor je een opdracht gaf om een kaart te ponsen moest eerst geteld worden hoeveel gaatjes de kaart zou gaan bevatten. Als het er teveel zouden worden, werd een foutmelding gegeven. De reden was dat als er te veel gaatjes werden geponst de ponsstiften niet door de kaart heen gingen maar het hele ponsblok omhoog ging en vaststloeg.

  • er waren geen speciale interrupts voor het pons- en leesgedeelte. In het interruptprogramma moest je eerst dus uitzoeken of je nu een kaart gelezen of een kaart geponst had.

Over het Algol-systeem nog het volgende: dynamisch laden van drivers deden we niet aan. Voor we konden testen moesten we dus eerst een compleet Algol-systeem assembleren. Dat hield in dat we echt tientallen ponsbanden moesten inlezen en weer oprollen.

Kleinere aanpassingen brachten we rechtstreeks in het geheugen aan. We kenden de interne machinecode van de EL-X8 uit ons hoofd (die was ook heel gestructureerd opgebouwd).

Een enkele instructie wijzigen was geen probleem. Dat deden we gewoon via de knopjes.

Lastiger werd het als we één instructie moesten vervangen door meerdere. Dan zetten we een sprong-opdracht op die plek naar een vrij stuk geheugen. Daar zetten we dan de benodigde instructies neer gevolg door een sprongopdracht terug.

Wel goede aantekeningen houden want het moest wel natuurlijk in de broncode ook aangebracht worden.

We zijn ook bij diverse klanten van Electrologica langs geweest om daar een Algol-systeem te installeren. Mijn min-of-meer chef had een koffer aangeschaft en daar zaten alle ponsbandjes in. Die moesten we in de goede volgorde assembleren. Dan testen we het systeem uit, pasten het evt. via de knopjes aan en als het goed was maakten we een binaire band zodat de klant zelf het systeem kon laden.

Wijzigen van ponsbanden is natuurlijk lastig. De ponsbanden werden gemaakt op een Flexowriter en daar kon je ook ponsbanden kopiëren. Op tijd stoppen, de nieuwe tekst invoeren en verder gaan.

Op een gegeven moment had iemand een soort editor gemaakt. Daardoor konden we een klein bandje met de wijzigingen inlezen, daarna de oude tekst en vervolgens werd de gewijzigde band uitgeponst. Een hele vooruitgang!

We hadden ook apparaatjes om een stukken ponsband aan elkaar te plakken. We zochten de tekst op, sneden daar de ponsband door, plakten een stuk blanco ponsband er tussen en prikten de tekst er in. De Flexowriter-code kenden we redelijk uit ons hoofd.
Hele moedigen wijzigden zo ook binaire band!

Je kon, als er een Flexowriter vrij was, zelf je programma's intikken of wijzigen. Er waren ook een tweetal dames die dat voor ons deden. Van eentje weet ik nog dat dat een behoorlijk slimme meid was. De man die belast was met de opleiding van nieuwe medewerkers had een Algol-programma gemaakt.

Voor de EL-X8 zag zo'n programma er ongeveer zo uit:

begin integer A,B,C;

array Lijst[1:100];

etc.

De keywords moesten dus onderstreept worden. Hij had dat op zijn ingeleverde tekst niet gedaan. Zij had keurig alle keywords onderstreept...

Ook de overgang van ponsband naar ponskaarten had al zijn voordelen: gewoon een enkele kaart vervangen door wat andere en je programma was weer aangepast. Alleen moest je geen bak met ponskaarten uit je handen laten vallen want aan volgordenummers deden we natuurlijk niet.

Ponsband had natuurlijk ook zijn nadelen. Iedereen stonk er wel eens in dat ze in een grote opgerolde ponsband achterin wat wilden aanpassen en dacht: ik haal het laatste stukje even eruit, ik pas het aan en ik rol alles weer terug. En als dat laatste stukje wat te lang was, dan lukte dat niet en zat je met een grote berg ponsbandsla.

Één van onze Amerikaanse gasten had ook zoiets uitgehaald. Ten einde raad had hij de ponsband vanuit de vierde verdieping in het trappenhuis naar beneden laten zakken. Toen kwam op de begane grond iemand voorbij die een rondleiding voor nieuwe medewerkers hield. Hij zag die ponsband, vertelde er iets over en trok er vervolgens aan. Van de vierde verdieping kwam een luidkeels “Goddam!!!.”

De machinecode van de EL-X8 was heel krachtig met de conditiezettende en de conditievolgende varianten van instructies plus het slim gebruik van de stack. Daarmee kon je heel compacte code schrijven. Dus we vielen elkaar regelmatig lastig met een soort codeerwedstrijden. “Ik heb weer een probleem. Ik heb dit in register zus-en-zo staan en ik wil dan het volgende: ….”. Iedereen aan de gang. “Ik heb het in acht instructies.”

“Ik in zeven.” “Ik in zes.” “Laat dat dan maar eens zien.”.

Op alle kamers hadden we grote schoolborden waarop we dit soort exercities konden uitvoeren. Daar waren ze natuurlijk niet alleen voor bedoeld. Die borden waren ook heel gemakkelijk bij allerlei discussies over technische onderwerpen. Maar soms dan stond er iets heel belangrijks op die borden en dan was het de volgende ochtend verdwenen. De schoonmakers haalden iedere avond een spons over die borden. Behalve als we in duidelijke letters NIET UIT!!! op het bord gezet hadden.

De instructieset van de EL-X8 was ontworpen om goed Algol-programma's te kunnen draaien. Je had adressering via het A- en S-register. Dat leverde instructies op als

VELD=MA[10]
Een indirectieslag via het A-register gevolgd door een verhoging met 10.

Daarnaast had de EL-X8 MC-adressering waarbij automatisch een stackpointer omhoog of omlaag ging.

MC=A
plaatste de inhoud van het A-register op de stack en verhoogde de stackpointer (het B-register) met 1.

Als je
MC=F
deed, dan ging B met 2 omhoog (F was het floatingpoint-register en bestond uit twee woorden).

Deed je
A=MC[-1]
dan werd de top van de stack in A geladen en ging de stackpointer weer met 1 omlaag.

Daarnaast had de EL-X8 de zgn. Mpq-adressering. Die bestond uit een indirectieslag via het pseudo-register D, een verhoging met p, weer een indirectieslag en een verhoging met q.

Deze adressering was gemaakt om in een blok in een Algol-programma in één klap bij data van lager gelegen blokken te kunnen komen. Dit zal alleen in gegenereerde code gebruikt worden want voor normale ELAN-programma's was het niet erg toepasbaar.

Niet alleen werken...

Op een ontwikkelafdeling is het vaak hollen of stilstaan. Soms, als er allerlei dingen af moesten, was iedereen ongelofelijk druk. En er waren ook tijden dat we niets te doen hadden. Dan was het weer wachten op een beslissing die in hogere regionen genomen moest worden.

In dat soort tijden werden ook de meest dwaze dingen gedaan. Ik herinner me nog de zgn. niet-wedstrijden. Wie kon het snelst een vol nietapparaat leeg krijgen.

In zo'n periode heb ik ook leren schaken. Wedstrijden tussen de ene groep en de andere. Er werd weer een zet doorgegeven en iedereen ging zich bemoeien met de volgende zet. Op een gegeven moment kwam er een missive van het management dat we het aantal zetten wel moesten beperken tot twee per dag.

Over het management valt ook nog wel wat te vertellen. Over de directeuren Loopstra en Scholten is veel te vinden, o.a. in het leuke boek Alles moest nog worden uitgevonden door de schrijfster met de fraaie naam Cordula Rooijendijk. Mijn eerste chef bij EL was ook een wat apart figuur. Vrij kort nadat ik daar was gekomen ging hij weg. Wat ging hij doen? Hij had een componeeropdracht gekregen!

Wat was het verhaal? Hij was na zijn middelbare school naar het conservatorium gegaan voor de componisten/dirigenten-opleiding. Na een paar jaar kwam hij tot de conclusie dat hij waarschijnlijk in de muziek niet echt zijn brood kon verdienen. Hij heeft toen een som geld geleend, heeft in een jaar tijd én zijn kandidaatsexamen Wiskunde gehaald én het conservatorium afgemaakt. Dat soort figuren liepen gewoon in het wild bij EL rond.

Er waren ook leuke buitenschoolse activiteiten (in de avonduren). Lezingen over allerlei zaken die met computers te maken hadden. Ik herinner me nog een lezing van prof. Edsger Dijkstra, de bedenker van het roemruchte THE-systeem. Het ging over hoe zgn. dodelijke omarmingen te vermijden: twee processen die oneindig op elkaar wachten omdat ze allebei iets hebben wat de ander ook nodig heeft. Dijkstra was natuurlijk een ster in het bedenken van heel aansprekende voorbeelden. Dit probleem illustreerde hij met twee koks waarvan de een soep maakt en de ander iets anders. Kok A had eerst het fornuis nodig en dan de mixer, kok B eerst de mixer en dan het fornuis.

Er was ook eens een presentatie over het een of ander programma dat op behoorlijk laag niveau opereerde (dwz. vrij dicht op de hardware). Op een gegeven moment vroeg iemand aan de spreker: is het hout? De spreker was waarschijnlijk enigszins perplex want hij had nog nooit van een houten programma gehoord.

Een houten programma was een programma wat op een hele basale manier I/O bedreef: de I/O-opdracht werd gegeven en er werd domweg in een loopje gewacht tot die I/O-opdracht klaar was. Het programma hield dus de computer in een houdgreep.

Mijn laatste klus voor de EL-X8 was de driver voor de harde schijven. Dat deden we met z'n drieën:

  • eentje deed het toewijzen van diskruimte aan bestanden. Wat we nu het filesysteem noemen

  • de tweede het vertalen van logische IO-opdrachten in fysiek uit te voeren opdrachten.
    Onder het Algol-systeem werd het de disk afgebeeld als een byte-adresseerbaar medium. Maar we hadden natuurlijk wel met sectoren e.d. te maken. Dus daar moest een laag tussen.

  • en ik deed het driver-gedeelte.

Heeft allemaal gewerkt maar of het ooit toegepast is????

Op de EL-X8 was ook een Fortran-compiler beschikbaar. Die was in Duitsland gemaakt en werd verder door Electrologica Nederland onderhouden. De grootte van programma's was, gezien de beperkte geheugenruimte, van uitermate groot belang. De mensen van de Fortran-groep zijn nog met een Duitser bezig geweest om de Fortran-compiler kleiner te maken. Dat ging als volgt:

  • de source-tekst van de compiler werd doorgevlooid

  • als ze ergens minstens drie of meer opdrachten tegenkwamen die meerdere keren voorkwamen, dan werd van die opdrachten een subroutine gemaakt en werden de opdrachten vervangen door een subroutine-aanroep. Dat leverde weer enkele instructies winst op. Het nadeel was dat je allerlei subroutines kreeg waarbij je absoluut niet kon zeggen dat de subroutine een redelijk wel omschreven functie uitvoerde

Het salaris

De salariëring was niet al te riant: we vielen onder de Philips-CAO en dat was niet de meest luxe van Nederland. Zo in 1969 begon het duidelijk te worden dat er iets moest gebeuren: de software-huizen en detacheringsbureaus werden wel erg grote concurrenten op de arbeidsmarkt en de een na de ander verliet Philips om zijn heil en een hogere beloning elders te zoeken.

Er werden stevige maatregelen genomen: een forse tussentijdse verhoging plus ook de toezegging van grotere salarisstappen. Op 1 januari 1970 was mijn salaris gelijk aan dat van 31 december 1969 PLUS dat van 1 januari 1969!

Maar de salarissen bij Philips bleven aan de lage kant. Ik heb, toen ik zo'n zeven jaar weg was bij Philips weer eens gekeken of er niet wat leuks te vinden was: ik was wel toe aan een andere uitdaging. Ze hadden mijn oude salaris doorgetrokken, gingen er vanuit dat ik ondertussen wel een functiegroep hoger terecht gekomen zouden zijn en kwamen toch Hfl. 10.000 onder wat ik toen verdiende. En daarvan had ik ook al niet het idee: wat betaalt dit bedrijf toch goed.

De P880

Daarna werden we betrokken bij de ontwikkeling van de P880. De P880 was een, voor die tijd, kleine wetenschappelijke computer. Klein wilde zeggen dat hij met een steekwagen was te vervoeren en geen geconditioneerde ruimte nodig had. Doelgroep: scholen, technische ontwikkelgroepen etc. Concurrentie: de IBM 1130.

De hardware werd bij Philips Frankrijk ontwikkeld in Fontenay-aux-Roses, een voorstad van Parijs. Daar zou ook het OS en de echte harde software als de linking loader e.d. ontwikkeld worden. Wij in Rijswijk zouden de compilers maken: Algol, Fortran en RUG, een RPG-achtige taal.

Omdat de hardware nog niet klaar was moesten we eerst een simulatiesysteem bouwen zodat de software- en de hardware-ontwikkeling parallel plaats kon vinden. Wij zouden dat op de EL-X8 doen, onze Franse collega's op een CDC-computer bij een servicecentrum.

Ik heb samen met een collega een cross-assembler gemaakt die draaide op de EL-X8, P880-assembler code las en ook P880-objectcode produceerde. Een probleem was dat wel de instructieset van de P880 bekend was maar niet de assembleertaal. Dat zijn toch twee aparte zaken die natuurlijk wel aan elkaar gekoppeld zijn. Een assembler moet één-op-één alle machineinstructies kunnen opleveren maar kan nog meer faciliteiten bevatten. Voorbeelden zijn bijv. de mogelijkheden om namen aan constante waardes te geven, geheugengebieden aan te kunnen geven, met lokale namen te kunnen werken, macro-faciliteiten etc.

Die assembleertaal hebben wij, in samenwerking met een Franse collega, vastgesteld. Dat leverde een reisje naar Parijs op. 's Middags heen, een avond in Parijs, een dag werken in Fontenay-aux-Roses en 's avonds weer terug. Mijn eerste bezoek aan Parijs en mijn eerste vliegreis!

In een andere groep werd de P880-simulator ontwikkeld. Die moest dus op de EL-X8 P880-programma's kunnen draaien.

Toen dat allemaal gedaan was, begonnen wij aan de Algol-compiler. Het technische ontwerp hebben we met z'n vieren gedaan. Hoe ziet de symboltable er uit (leek sterk op die van de EL-X8 compiler), hoeveel passes zou de compiler bevatten, wat waren de interfaces tussen de passes etc.

Daarna hebben we met z'n tweeën de passes ontworpen en gemaakt die voor de echte vertaling zorg moesten draaien.

Ik heb toen nog PSALG gemaakt, een pseudo-Algolcompiler, die input voor de verschillende passes kon leveren om parallel te kunnen testen. De compiler was zeer rudimentair: bij de eerste beste fout in het programma stopte PSALG en je moest je testprogramma afsluiten met een hele rij punt-komma's. Maar hij werkte en we konden er mee testen.

Toen kwam het grote moment: we moesten op echte hardware gaan testen. Er waren twee mogelijkheden: zorg er voor dat er een P880 in Rijswijk kwam (incl. een hardware-technicus) of breng de software-ontwikkelaars over naar Parijs. Voor dat laatste is toen gekozen. Een prachtige tijd. We werden ondergebracht in hotels in Montparnasse en gingen iedere dag met een treintje naar Fontenay-aux-Roses. Gelukkig wel want daar was wel heel erg weinig te beleven. Maandagochtend heen (per vliegtuig) en donderdag weer terug (eerst op vrijdag maar dat vonden we toch te heftig). Dit speelde zich in 1970, 1971 af. Ik was de jongste van de groep en ging met oudere collega's naar Parijs. Heel hard gewerkt maar het gebeuren er om heen was ook erg leuk. Van Parijs hebben we niet zoveel gezien. Daar hadden we geen tijd voor maar ik heb er wel kennis gemaakt met de Franse keuken en zaken leren eten als mosselen, niertjes etc en het genot van een calvados na het eten leren kennen. En mijn drankvoorraad groeide gigantisch want toen kon je nog op dit soort vluchten belastingvrij drank kopen. En als je aan het hoofd staat van vijf flessen whisky denk je: nu maar eens wat anders. Dat werden dan dranken als Benedictine, Cointreau etc. Ik heb er nog jaren plezier van gehad.

We waren al een hele tijd aan het testen toen de boodschap kwam dat een selectie-commissie van een aantal HTS-en geïnteresseerd was om evt. P880's te kopen. Dat zou heel mooi zijn. Maar dan moesten we wel wat kunnen laten zien.

Ze hadden een batch van Algol-programma's die op de IBM 1130 gedraaid had en ze wilden dat wij lieten zien dat wij dat ook konden en in een acceptabele tijd. Die Algol-programma's moesten wel aangepast worden, vnl. de I/O-opdrachten (de bijbel voor Algol-compilerbouwers, het Revised Report, definieerde wel wat Algol moest zijn maar liet zich niet uit over hoe je wat moest lezen of printen. Dus iedereen bedacht andere oplossingen. Wij hadden absoluut geen tijd om door al die kleine programmaatjes heen te gaan. Daarvoor kwam iemand van de marketingafdeling over. Die ploos al die programma's uit, paste de I/O-statements aan en testte ze. Toen ontdekte hij in een aantal programma's een aantal kaarten met binaire informatie. De IBM-ers hadden, om de snelheid van uitvoering op te peppen, een aantal zgn. code-procedures (in feite machinecode) in de programma's gestopt...

Wij waren op tijd klaar (wat niemand verwacht had) en de batch draaide (zonder code-procedures) in een fractie van de tijd die IBM nodig had gehad. De commissie kwam, we lieten zien dat wij in korte tijd die hele batch konden draaien. We waren zo zelfverzekerd dat wij ze uitnodigden zelf ook maar eens een programmatje te maken. Dat leverde maar één compiler-abort op die we gelukkig weg konden moffelen. Maar volgens mij is het met die order nooit wat geworden.

Fortran-G-compiler

Daarna vielen we in een soort gat. Wat nu? Werk voor de P1000. We hebben nog gekeken of een soort Basic mogelijk was op de P1000 maar dat is niets geworden.

Toen kwam er behoefte aan een Fortran-G-compiler voor de P1000. Fortran G was een dialect van Fortran dat door IBM ontwikkeld werd en deze compiler was nodig om een klant over te laten stappen van IBM naar Philips.

De bouwgroep van deze compiler was voor een deel dezelfde die ook de Fortran-compiler voor de P880 had gemaakt. Ik werd daaraan toegevoegd.

Philips had ondertussen SPL gemaakt: System Programming Language. We spreken van voor de tijd dat talen als C bestonden.

SPL was een sub- en superset van PL/I gericht op het maken van systeemsoftware. Voor die tijd werd dat altijd in Assembler gedaan en dat is toch moeizamer ontwikkelen.

Het was een subset omdat een heleboel zaken uit PL/I weggehaald waren. Omdat ze niet nodig waren (in systeemprogrammatuur heb je geen behoefte aan decimaal of floating-point rekenen) of omdat ze te zwaar waren en onnodige ballast opleverden (array-slices en exceptions bijv.).

Het was een superset omdat een aantal beperkingen die in PL/I zaten er uit gehaald waren. Bijv. je kon onbeperkt pointers manipuleren en het was mogelijk om in de SPL-code Assembler-statements op te nemen. Ontwikkelaars van systeemprogrammatuur worden geacht te weten wat ze doen en hoeven niet tegen zichzelf in bescherming genomen te worden.

Ik had al wat gefröbeld met SPL dus ik heb mijn collega's wegwijs gemaakt.

Overigens was er wel weerstand tegen het gebruik van SPL in plaats van Assembler. De programma's worden groter, was natuurlijk een belangrijk argument. Dat telde zeker in de tijd dat geheugens in KB's werden gemeten en niet in MB's, laat staan in GB's. En virtueel geheugen was ook maar pas uitgevonden (en dat moet natuurlijk wel door de hardware ondersteund worden).

Daar is onderzoek naar gedaan. Daaruit bleek dat de programma's inderdaad groter werden (hoevel dat wel meeviel) maar er waren ook gevallen dat ze kleiner werden. Dat kwam voornamelijk voor bij programmatuur die aangepast moest worden. Omdat niet altijd erg duidelijk was wat wel en niet kon, werden er soms overbodige dingen gedaan onder het (terechte) motto: better safe than sorry.

We gingen voor de Fortran-G-compiler dus SPL gebruiken.

Dit was nog voordat er tools als yacc en lex ontwikkeld waren. Dus voor iedere compiler werd alles weer vanaf nul gemaakt. Als waren er wel onderdelen die we zo konden overnemen.

Ik zat op mijn verzoek aan de voorkant van de compiler: de syntax-herkenning.

Ik herinner me nog een probleem wat we moesten tekkelen (dat gold voor iedereen die een Fortran-compiler maakt).

Spaties zijn in Fortran niet verplicht en mogen dus overal staan en overal weggelaten worden.

Een probleem is dan om te herkennen wat een toekenningsstatement is.

Bijv.

A=B*3

is niet moeilijk

DO 10 I=1,10

introduceert een loop maar

DO 10 I=1.10

is een toekenningstatement aan de variabele DO10I

In de P880-compiler was een lijstmechanisme gebruikt. De vrije ruimte was onderverdeeld in een aantal lijstjes (de symboltable, de source-tekst etc.). Als je in die compiler iets aan een lijst wilde toevoegen dan moest je het lijstmechanisme aanroepen met het nummer van de lijst en het aantal bytes dat je nodig had. Het lijstmechanisme keek of het mogelijk was, reorganiseerde evt. de vrije ruimte door met lijsten te schuiven en schreef, als het nodig was, sommige lijsten ten dele naar disk. Daarna kon je via een pointer de lijst accessen.

Al met al een behoorlijke overhead. Ik heb toen een wat getruceerd mechanisme bedacht dat, met wat complicaties, goed gewerkt heeft.

In de P1000 kon je in je programma aangeven dat je overflow wilde maskeren of als fout wilde laten aanmerken. En je kon een exception-handler specificeren voor bepaalde fouten. Daar hebben we gebruik van gemaakt.

Bij iedere lijst hoorde een teller met als waarde 32768 minus de vrije ruimte. Als je wat aan een lijst wilde toevoegen, telde je het aantal bytes bij de teller. Als er niet voldoende ruimte was, trad er een overflow op, werd de exception-handler geactiveerd en konden we de vrije ruimte reorganiseren.

De complicatie was dat de SPL-compiler soms te slim was en niet in de gaten had dat een pointer gewijzigd kon zijn. In C++ is hiervoor het volatile keyword uitgevonden met als betekenis: deze variabele kan door externe invloeden een andere waarde krijgen dus optimaliseer de accessen van deze variabele niet. Dat zat niet in SPL dus moesten we soms trucs toepassen om de compiler van ongewenste optimalisaties af te houden.

Het lijstmechanisme heeft uitstekend gewerkt. We hadden 80K woorden beschikbaar voor de compiler waarvan we 40K voor de lijsten reserveerden. De meeste programma's konden in core gecompileerd worden met maar enkele activeringen van het mechanisme. Dus de compiler had een hele hoge compileersnelheid.

MMS

Daarna wilde ik wel eens wat anders en kwam ik bij de MMS-groep terecht. MMS was ontwikkeld als een nieuw OS voor de middelgrote P1000's. Het kon meerdere programma's tegelijk draaien, de programma's konden overal in het geheugen staan en het OS had datacommunicatie-faciliteiten. Het OS was gebaseerd op GMF, General Monitor File. Één source-base van waaruit een aantal verschillende OS-en gegenereerd kon worden.

Ik werd eerst aan de afhandeling van operator-commando's gezet maar al snel was duidelijk dat ik daarmee niet mijn dagen kon vullen. Dus werd ik ook aan de job scheduler gezet.

De job-scheduler (het enige onderdeel dat in SPL geschreven was) werd geactiveerd als het OS vermoedde dat er wellicht nog wel een job bij kon.

Ik zat op één kamer met twee anderen. Ik was zelf zo'n 27 jaar, de tweede was rond de veertig en de derde een vijftiger. Ik was toen al een paar jaar lid van de PvdA en de vijftiger was fractievoorzitter van de VVD in Berkel-Roderijs. Het was in de tijd van het kabinet Den Uyl dus dat leverde wel eens stevige discussies op. Met soms wat stemverheffing waarbij collega's kwamen kijken wat er nu weer aan de hand was. We konden het dus uitstekend met elkaar vinden.

Hierna kwamen de plannen voor de P2000, de beoogde opvolger van de P1000. Ik werd teruggehaald naar de compilergroep en we begonnen te kijken naar het wat-en-hoe van een Cobol-compiler.

Het einde

In september 1975 barstte de bom. We werden allemaal naar de kantine geroepen. Daar werd ons verteld dat het Unidata-avontuur was afgelopen en dat Philips uit de grote computers zou stappen.

Het personeelsbestand van Philips Data Systems moest van 5000 naar 2500.

Het echte verhaal achter de pogingen van Philips op het gebied van computers heb ik pas begrepen toen ik jaren later het boek 'Kortsluiting' van Marcel Metze las. We stonden echt te ver van de bovenlaag af om daar enig zicht op te hebben.

De leegloop begon. Ik kon per 1 december 1975 beginnen als systeemprogrammeur bij een uitgeversmaatschappij/boekenclub.

Ik was nog te vroeg weg: op een gegeven moment werd aan mensen die niet op de 'jou willen we houden'-lijst terecht kwamen, een oprot-premie van vijf maandsalarissen aangeboden.

Dat was het einde van bijna tien jaar werken bij Electrologica/Philips Electrologica/Philips Data Systems. Ik heb daarna nog meer dan 30 jaar in de ICT gewerkt maar dit was wel de periode waar ik het meeste van geleerd heb. Er zijn niet zoveel plekken in Nederland waar je drivers kunt maken, compilers kunt bouwen en aan besturingssystemen kunt sleutelen.