Philips P1000

De P1000 was de serie grote computers waarmee Philips geprobeerd heeft een speler op dit terrein te worden.

Ik ben zelf vrij laat aan de P1000 gaan werken (1971 en later). Ik ben betrokken geweest bij een tweetal projecten:

  • ontwerpen en bouwen van een Fortran G-compiler
  • uitbreiden en onderhouden van MMS, het multiprocessing operating systeem voor middelgrote computers.

De Fortran-G compiler

Fortran-G was een uitbreiding op Fortran die IBM geïmplementeerd had. Het manual van IBM was dan ook ons referentiekader.
De groep die de Fortran-G compiler bouwde bestond voor een belangrijk deel uit mensen die ook de Fortran-compiler voor de P880 gemaakt hadden.
Inmiddels had Philips SPL ontwikkeld. Daarin is dan ook de Fortran-compiler voor het overgrote deel gemaakt.
Deze Fortran-compiler had voldoende aan 80K bytes voor code en werkruimte en performde uitstekend. Voor een deel werd dat veroorzaakt doordat tussencode en tabellen zoveel mogelijk in het geheugen gehouden werden. Als dat niet lukte werd eerst de tussencode naar schijf weggeschreven maar in de praktijk bleek dat vrij grote programma's geheel in het geheugen vertaald werden.

Een Fortran-compiler moet vrij veel aparte lijstjes bijhouden: de symboltable natuurlijk maar ook informatie over DO-statements, over DATA-statements etc.
Je kon alles in één grote tabel gooien en de bijbehorende data met pointers aan elkaar linken. Het geheugenbeheer werd hierdoor simpeler maar de tabel werd ingewikkelder.
In de P880-compiler was gekozen voor allemaal aparte lijsten. Omdat de grootte van deze lijsten niet van te voren bekend was, moesten het lijstgebied gereorganiseerd kunnen worden. Lijsten konden on the fly op een andere plaats terecht komen. Access van lijsten moet dus altijd via pointers die naar het begin van de lijst wezen gedaan worden.
Om iets aan een lijst toe te voegen moest eerst het lijstmechanisme aangeroepen worden om ruimte te reserveren. Dit leverde een behoorlijke overhead op.

In de P1000-compiler werd gebruik gemaakt van een specifieke eigenschap van de P1000. Overflow kon gemaskeerd worden of kon ook als foutconditie aangemerkt worden.
Verder konden gewone gebruikersprogramma's (wat een compiler tenslotte is) exit-handlers specificeren om bepaalde fouten af te vangen. In de exit-handler kon dan bepaald worden of doorgegaan kon worden of niet.
Door de vrije ruimte in een lijst bij te houden in 16-bits integer waarin de waarde 32768 - <vrije ruimte> stond, moest voor het aanvragen van ruimte alleen deze waarde verhoogd te worden. Kwam er een overflow dan kon de exit-handler de werkruimte reorganiseren, de pointers naar het begin van de lijsten aanpassen en doorgaan met het vertalen.

Een complicerende factor hierbij was het optimaliseren wat de SPL-compiler deed. Een voorbeeld:

 PTR=LIJSTPTR(4)+INDEX;   ... doe wat via PTR .... 
LIJSTCNT(4)=LIJSTCNT(4)+20; // reserveer 20 bytes
PTR=LIJSTPTR(4)+INDEX; // LIJSTPTR kan gewijzigd zijn!!
De compiler wist dat de waarde van LIJSTPTR(4) nog in een register stond en gebruikte die in plaats van code te genereren die de waarde weer ophaalde. In C++ is dat opgelost door het volatile-attribuut te specificeren met als betekenis: deze variabele kan door externe factoren gewijzigd worden
In SPL bestond zoiets niet (hoewel we wel voorgesteld hebben dat er in te brengen) dus moesten we dat als volgt oplossen:
PTR=LIJSTPTR(4)+INDEX;   ... doe wat via PTR ....
LIJSTCNT(4)=LIJSTCNT(4)+20; // reserveer 20 bytes
LOZE_LABEL: PTR=LIJSTPTR(4)+INDEX; // LIJSTPTR kan gewijzigd zijn!!
....
....
RETURN; // verlaat procedure
LOOS: GOTO LOZE_LABEL;
Gelukkig was de compiler niet zo slim dat hij de dode code bij LOOS er uit gooide....

MMS

Philips had voor zijn P1000-series in eerste instantie drie operating systemen:
  • een single-run operating systeem (1 batch-programma tegelijk)
  • een single-run operating systeem met datacommunicatie faciliteiten.
    Datacommunicatie in de voorgrond en 1 batchjob in de achtergrond.
  • een multiprogrammerings operating systeem voor de grote systemen
Om multiprogrammering voor de wat kleinere systemen mogelijk te maken was MMS ontwikkeld. MMS kon een variabel aantal programma's aan. IBM bood toen op systemen van de omvang waar MMS voor bedoeld was MFT aan: Multiprogramming met een Fixed number of Tasks. Wat mij bijstaat moest je op MFT een programma altijd in een vaste partitie laten draaien. MMS was daar veel soepeler in: het aantal gelijktijdige programma's werd bepaald door de load op het systeem en het resourcegebruik en was niet vast. Een programma kon op iedere plek in het geheugen draaien.

Ik was bij de MMS-groep terecht gekomen omdat ik wel eens wat anders wou na zoveel jaar compiler-bouw. Ik heb daar twee jaar gezeten en me bezig gehouden met de operator-commando afhandeling en de job selector, het programma dat keek of er ruimte was om een nieuwe batchjob te starten en welke dat dan zou moeten zijn.

Een foto van een maquette tbv verkoopdoeleinden (met dank aan Adrian Stoness uit Canada)