EWD 91

Samenvatting van oordeel over het "Voorstel tot aanschaffing van een digitale informatieverwerkende machine voor de afdeling der elektrotechniek".

De motivering stelt wel de behoefte aan beschikking over digitale apparatuur, maar laat na aan te tonen, dat deze behoefte niet door de reeds door de THE bestelde machine bevredigd zal kunnen worden en dat dus de aanschaf van een extra machine gerechtvaardigd is.

De motivering noemt wel een aantal toepassingsgebieden, waar een digitale machine bij ingeschakeld zou kunnen worden, maar geeft geen helder beeld van de daaruit voortvloeiende eisen, aan deze machine te stellen. In plaats daarvan bevat het voorstel een lijst van acht deugden van de voorgestelde machine, een IBM 360. Bij nadere inspectie vragen ten minste zes van deze acht wel om enige relativering.

De voorgestelde machine is conventioneel. Door een nodeloze explicietheid van de opdrachtcode deelt zij met haar voorgangers in onverminderde mate de onaangename eigenschap van "onprogrammeerbaarheid", zoals ook blijkt uit de mate, waarin vertaaltijden voor in alogorithmische talen geschreven programma's ten gevolge van optimalisatiepogingen gegroeid zijn. In uniprogrammering zijn deze optimalisatiepogingen al gebrekkig, in multiprogrammering, waar tijdens vertaling van een individueel programma de omstandigheden, waaronder dit programma later zal werken, zoveel minder bekend zijn, zijn ze nog heillozer.

Dit, en de beperkte middelen, waarmee de onderlinge synchronisatie tussen geprogrammeerde en zich buiten de centrale rekeneenheid afspelende processen geregeld moet worden, versterken mijn indruk, dat de ontwerpers zich onvoldoende bewust zijn geweest van de consequenties, die de veranderde werkomstandigheden met zich meebrengen. Zijn geschiktheid voor multiprogrammering en procescontrole - twee nauw verbonden doelstellingen - acht ik dan ook niet overtuigend : hij zal er met pijn en moeite, en mits men met niet te veel al tevreden is, wel voor gebruikt kunnen worden.

De in het voorstel geschatte personeelsformatie van slechts vier man komt mij hierom optimistich voor. Bij deze schatting gaat de afdeling er van uit "dat een toenemend aantal medewerkers zelf zal kunnen programmeren". Wanneer dit gaat impliceren -en daar ben ik bang voor- dat een toenemend aantal medewerkers hun tijd zal moeten besteden aan de toch irrelevante problemen, die rijzen, wanneer men een stuk gereedschap wil inzetten voor taken, waarvoor het eigenlijk niet het adequate stuk gereedschap genoemd kan worden, dan wil ik hierbij opmerken, dat ik uit educatieve overwegingen hier ernstige bezwaren tegen zou koesteren.

Tenslotte: de eigenschappen van de arithmetiek met drijvende komma tarten, zoals dat heet, elke beschrijving. Ik heb nochtans deze uitdaging niet onbeantwoord kunnen laten.

15 juni 1964                                                        E.W.Dijkstra


Aan de hooggeleerde heer
prof. dr.ir.A.A.Th.M.van Trier
voorzitter-beheerder van de
afdeling der electrotechniek

Zeer geachte Collega,

aan Uw namens de afdeling der electrotechniek tot mij gerichte verzoek mijn oordeel te geven over het "Voorstel tot aanschaffing van een digitale informatie-verwerkende machine voor de afdeling der electrotechniek" voldoe ik volgaarne.

Mijn commentaar spruit voornamelijk voort uit een confrontatie van de in dit voorstel gegeven motivering met de gedane keuze. Wanneer ik tot de conclusie kom, dat de gegeven motivering weinig overtuigend is - een conclusie, waartoe het College van Curatoren dan dus ook zou kunnen komen -, dan verzoek ik U, ter voorkoming van misverstand, U er wel van bewust te zijn, dat dit niet hoeft te impliceren, dat ik tegen een effectuering van de voorgestelde aanschaffingen gekant zou zijn.

Het voorstel begint met een beroep op het inrichtingsplan van 18 juni 1963 van de groep Telecommunicatie-B, waarin gesteld wordt, dat "de afdeling der electrotechniek .... op een nader te bepalen tijdstip de beschikking (zal) moeten hebben over een digitale rekenmachine, die geschikt is voor besturingsfuncties.".

Na dit citaat vervolgt het voorstel met "Thans is de meningsvorming binnen de afdeling der electrotechniek zover gevorderd, dat U een concreet voorstel kan worden gedaan tot aanschaffing van.....etc.etc.", waarbij stilzwijgend ervan is uitgegaan, dat de behoefte, die met "de beschikking hebben over" is aangeduid, het beste door een nieuw aan te schaffen apparaat kan worden bevredigd. Zo rijst onmiddelijk de in het voorstel onaangeroerde vraag, in hoeverre de behoeften van de afdeling der electrotechniek mettertijd bevredigd zou kunnen worden onder gebruikmaking van de reeds door de THE bestelde digitale apparatuur. Van de daaropvolgende uitspraak uit het voorstel : "daarnaast hebben ook andere groepen van de afdeling er belang bij, dat over digitale apparatuur kan worden beschikt" zou ik dan ook willen opmerken, dat hij zonder nadere specificatie niet als argument kan dienen en daarom in deze vorm mij als misplaatst voorkomt.

In de volgende passage, lopend van "Bij het ontwerp van electrotechnische systemen...." (pagina 1, regel 14 van onderen) tot en met "...niet meer adequaat worden uitgevoerd." (pagina 2, regel 19 van boven) hoor ikeen lofzang op de general purpose rekenautomaat, die mij uit de aard der zaak als muziek in de oren klinkt. Maar ook deze uitspraak treft mij meer als een bevestiging van de toekomstverwachtingen, die vorig jaar geleid hebben tot de bestelling van een grote rekenautomaat, dan als een deugdelijke motivering voor de aanschaf van nog een nieuwe machine !

Het voorstel vervolgt echter met : "De afdeling meent - en zij wordt in deze mening gesteund door anderen en ervaringen van elders - dat van de aanwezigheid van een digitale machine van bescheiden omvang een zeer stimulerende invloed zal uitgaan op wetenschappelijk onderzoek en ontwikkelingswerk." Deze alinea, die de stap van "beschikken over" tot "aanschaf" zou moeten rechtvaardigen, is om diverse redenen nogal zwak. "De afdeling meent"..... en dan komt er niet, wat je zou verwachten, nl. een bondige aanduiding op grond waarvan de afdeling deze mening koestert, maar... een anonieme verwijzing naar anderen en ervaringen van elders, alsof de afdeling in de gefundeerdheid van haar eigen mening onvoldoende vertrouwen heeft. (Waarom immers anders dit beroep op anderen ?). Er is nog een reden, waarom dit beroep op elders beter weg had kunnen blijven. Het gaat immers uit van de veronderstelling, dat de situatie zoals die zich in het verleden elders heeft voorgedaan, voldoende overeenkomst met de toekomstige situatie aan de THE zal vertonen, een prognose, waarvan ik vurig hoop, dat zij onjuist zal blijken ! (Uit het verzoek van de onderafdeling der wiskunde, gedaan in de "Letter to the Manufacturers" om de offerten zo mogelijk niet tot de toen reeds gangbare marktartikelen te beperken, bleek wel, dat zij met die gangbare marktartikelen niet onverdeeld ingenomen was, met name omdat zij zich voorstelde een gevarieerdere en zo nodig promptere service te leveren, dan daarmee mogelijk was gebleken. Dit streven van de onderafdeling der wiskunde heeft nog niets in kracht ingeboet en het is dan ook wat moeilijk om in Uw beroep op ervaringen van elders een blijk, zo niet van wantrouwen, dan toch wel van twijfel ten aanzien van dit streven te proeven.)

Tot zover de eerste twee regels van deze alinea ; ook de er in uitgesproken mening werpt een aanzienlijk vraagteken op. Uit het voorkomen van de nadere bepaling "van bescheiden omvang" valt wel te concluderen, dat de afdeling der electrotechniek de mate, waarin de aanwezigheid van een digitale machine wetenschappelijk onderzoek stimuleert, afhankelijk stelt van de omvang van deze machine, maar de lezer blijft geheel in het ongewisse over de aard van deze afhankelijkheid. Is de afdeling reeds geholpen met een machine van bescheiden omvang, maar zou zij met een grotere machine beter gebaat zijn, of is in haar toepassingen de bescheidenheid van de omvang der installatie juist een essentiele deugd ? Beide mogelijkheden zijn denkbaar,

Ook de volgende alinea vraagt om ophelderingen. Ten gunste van de IBM 360 wordt gezegd "dat dit systeem het resultaat is van een zeer geavanceerde ontwikkeling, zowel op technologisch gebied als op het gebied van de beginselen van informatieverwerking, die erin zijn toegepast." De beoordeling van de technologische merites - waarvan ik volgaarne aanneem, dat zij zeer groot zijn - valt buiten mijn competentie ; wanneer "de beginselen van informatieverwerking, die erin zijn toegepast" geacht kunnen worden terug te vinden te zijn in de manier, waarop de machine zich aan de programmeur voordoet, dan vraag ik mij in de eerste plaats af, welke deze beginselen dan wel zijn, en in de tweede plaats, waaraan zij dan wel het epitheton ornans "resultaat van een zeer geavanceerde ontwikkeling" - voorwaar geen zwakke term ! - aan mogen ontlenen. Bij de bestudering van "IBM System/360 Principles of Operation, form A22-6821-0" kreeg ik nl. niet de indruk van een moderne machine, integendeel. De voorstelling van zaken, dat het hier gaat om het resultaat van een zeer geavanceerde ontwikkeling acht ik, voorzover het de niet-technologische aspecten betreft, dan ook volledig misplaatst : zij treft mij meer als het product - en daarmee onderdeel - van een mythevorming, dat het hier om een achtste wereldwonder zou gaan, dan als een weloverwogen oordeel, getoetst aan de critische maatstaven een Nederlandse instelling van hoger onderwijs waardig.

Ten aanzien van de in het voorstel genoemde voordelen het volgende.

ad 1) "grote snelheid waarmee de logische handelingen worden uitgevoerd".

Aangezien deze snelheid, als ik het goed begrepen heb, van model tot model sterk verschilt, is dit argument meer van toepassing, naarmate Uw afdeling de aanschaf van een snellere versie voorstelt. Welke versie Uw afdeling op het oog heeft staat in het voorstel merkwaardigerwijs niet vermeld. Uit de prijsopgave meen ik te mogen opmaken, dat U het oog heeft laten vallen op een van de langzaamste versies, wat ik ervaar als een verzwakking van dit argument. Onafhankelijk daarvan zij opgemerkt, dat de snelheid voor alle versies voor een niet onbelangrijk gedeelte te niet gedaan wordt door onbeholpenheid van de opdrachtcode. Het feit, dat het merendeel der opdrachten de zg. Condition Code onherroepelijk wel of niet zet, terwijl alleen de sprongopdrachten op de zetting vann deze condition code kunnen reageren, eist in dit opzicht een zware tol.

ad 2) "de mogelijkheid meerdere programma's gelijktijdig uit te voeren".

Terzijde zij ten eerste opgemerkt, dat het woord "gelijktijdig" de werkelijke gang van zaken te gunstig voorstelt, aangezien de Centrale Processing Unit op elk moment maar met 1 (en indien door communicatie geblokkeerd, met geen enkel) programma actief bezig is.

Om tot de kern van dit punt te komen : het is sinds jaar en dag bekend, dat de mogelijkheid tot interruptie een nodige voorwaarde is om een soepel werkend systeem voor multiprogrammering te realiseren, het is, eveneens sinds jaar en dag, bekend, dat de mogelijkheid tot interruptie opzichzelf een onvoldoende voorwaarde is om de potentiele vruchten van multiprogrammering metterdaad te plukken. Het genoemde IBM-document is hier, dacht ik, wel wat misleidend ; ik citeer "By storing the current PSW (=Program Status Word) during an interruption the state of the CPU can be preserved...." (pg.15, rechterkolom, 5de regel van onder) en "If, at the conclusion of the interruption routine, there is an instruction to make the old PSW the current PSW the system is restored to the state prior to the interruption and the interrupted routine continues." (pg.16, linkerkolom, 5de regel van onder). Helaas is overschakelen van het ene programma naar het andere een aanmerkelijk omvangrijkere taak, aangezien de CPU is uitgerust met 16 enkelwoords- en 4 dubbelwoordsregisters, zodat 96 bytes gered moeten worden, voordat het andere programma kan doorgaan. (Ik ga er op dit moment aan voorbij, dat ook in uniprogrammering de aanwezigheid van een dergelijk groot aantal onderling gelijkwaardige speciale registers niet een onvermengde zegen is : zodra men probeert ze te gebruiken, blijkt het een tweesnijdend zwaard te zijn.) Voorts is het, om de vruchten van multiprogrammering te kunnen plukken, wel wenselijk, dat programma's herplaatsbaar zijn, en wel herplaatsbaar in een wat sterkere zin, dan waarin door deze machine voorzien wordt. Bij punt 7 kom ik hier op terug.

ad 3) "ruime en flexibele communicatiemogelijkheden".

Het is in dit verband speciaal het multiplexor channel, dat fascinerende mogelijkheden schijnt te bieden. Hoe bruikbaar het is, hangt echter af van nadere specificaties, die ik in het geciteerde IBM-document niet heb kunnen vinden. Mondeling is mij meegedeeld - of dit juist is, zou geverifieerd kunnen worden - dat in geval van congestie over het multiplexor channel bij niet stopbare inputapparaten informatie verloren gaat. En congestie is (zie de zg. burst mode) geen exceptie. De eerste vraag is of de CPU kan controleren, dat zulk informatie verlies niet is opgetreden. De tweede vraag is : wanneer er wel stopbare inputapparaten aan het multiplexor channel gekoppeld zijn, kan dan de terugkoppeling tussen channel en apparaat gerealiseerd worden, die in het geval van congestie in het kanaal het apparaat stopt ? Indien niet beide vragen bevestigend beantwoord worden, lijkt mij de bruikbaarheid van het multiplexor channel ernstig geschaad.

Voorts heeft het mij bij het multiplexor channel bevreemd, dat de interrupties van dit kanaal, hoewel er een groot aantal onderling asynchrone apparaten via dit kanaal kan worden aangesloten, tesamen slechts met ÈÈn enkel zg. "mask bit" tegengehouden, dan wel toegelaten worden. De mask bits zijn immers een mogelijkheid om selectief op interrupties te reageren, men zou ze bv. willen gebruiken om tijdens de behandeling van interrupties van gemiddelde prioriteit de CPU wel af te schermen tegen interrupties van lagere, maar niet tegen interrupties van hogere prioriteit. Als nu aan het multiplexor channel maar 1 apparaat zit, waarvan met de interruptie met hoge prioriteit wil honoreren, terwijl de overige interrupties via het multiplexor channel niet de minste haast hebben, dan zie ik hier een conflictsituatie ontstaan.

Bij de selector channels, die voor zover het informatietransport betreft, sequentieel bedreven worden, doet zich deze moeilijkheid niet voor. Hier is echter de vraag of de "command chaining" het soulaas brengt, dat ermee beoogd wordt. Twee vragen zijn bij mij gerezen, waarop ik in de mij ter beschikking staande documentatie het antwoord niet heb kunnen vinden. Indien aan een selector channel een ketting commands is gegeven en het kanaal is met de uitvoering van deze ketting begonnen, kan dan deze ketting nog met nieuwe schakels uitgebreid worden, maw. kunnen de commands continue toegevoerd worden ? Als dit niet het geval is - en daar ben ik een beetje bang voor - zou ik ernstig teleurgesteld zijn. De tweede vraag, die rijst, betreft de PCI-flag (Program Controlled Interruption), die in een CCW (Channel Command Word) mag voorkomen. Indien in een keten van commands meer dan 1 CCW de PCI-flag bevat, is het dus mogelijk, dat de tweede "interrupt condition" ontstaat, voordat de eerste gehonoreerd is. Het geciteerde document (pag 100, rechterkolom, regel 18 van boven) vervolgt : "The PCI-conditions are not stacked ; that is, if another CCW is fetched with a PCI-flag before the interruption due to the PCI-flag of the previous CCW has occurred, only one interruption takes place." Mijn vraag is, of de CPU kan achterhalen, dat deze ene interruptie voor twee (of meer) telt ; zo nee, dan lijkt me de faciliteit zo goed als onbruikbaar.

ad 4) "directe toegang tot het kerngeheugen, capaciteit van het kerngeheugen, mogelijkheid van bescherming van delen van het kerngeheugen".

In hoeverre "directe toegang tot het kerngeheugen" na punt 3 nog iets nieuws toevoegt, ontgaat mij. Hoe men "capaciteit van het kerngeheugen" als facet kan noemen, ontgaat mij eveneens : elk kerngeheugenheeft een zekere capaciteit ! De voorgestelde aanschaf omvat een kerngeheugen van "16000 tekens" (hiermee is bedoeld "16384 bytes" ?). Betekent de speciale vermelding "capaciteit van het kerngeheugen" dat de onderafdeling der electrotechniek haar keuze op de IBM 360 heeft laten vallen omdat deze leverbaar was met een geheugen van deze, door haar ideaal geachte omvang ? Of is hier eigen-omvang" bedoeld en houdt de afdeling reeds thans ernstig met de mogelijkheid rekening, dat de voorgestelde aanschaf in een later stadium als "stepping stone" (of in goed Nederlands : "als hefboom") tot een grotere installatie zal fungeren. In het voorstel zou wat grotere klaarheid in dit opzicht dunkt me wel gewenst zijn ; ik stel me zo voor, dat ook het College van Curatoren wel zal willen weten, of deze aanschaf beschouwd moet worden als hoofdzakelijk een eenmalige investering, dan wel of het met de fiattering van deze aanschaf zich voor latere jaren de (misschien kostbare) plicht tot uitbouw van de installatie op de hals heeft gehaald.

Ten aanzien van de genoemde "mogelijkheid van bescherming van delen ven het kerngeheugen" (mogelijkheid tot bescherming van informatie in delen van het kerngeheugen geeft het iets duidelijker weer) wil ik graag beginnen met de opmerking, dat ik de wijze, waarop dit in de IBM 360 met behulp van de zg. "Protection Key" gerealiseerd is, de leukste manier vindt, die ik ooit gezien heb. Het feit, dat deze methode met drastische uitbreiding van het kerngeheugen verenigbaar is weegt ongetwijfeld zwaarder dan de er uit voortvloeiende beperking, dat het aantal ten opzichte van elkaar beschermde processen aan een bovengrens van 15 gebonden is. Mijn appreciatie voor de wijze van verwezenlijking neemt niet weg, dat ik van de bruikbaarheid maar weinig overtuigd ben. Ten eerste gaat de geheugenbescherming in eenheden van 2048 bytes, met een slechts acht maal zo groot geheugen een tamelijk grove "korrel". Ten tweede - en dit is een aspect, waardoor de machine me als ouderwets treft - beoogt de geheugenbescherming om de ene programmmeur te beschermen tegen de fouten van een ander. Het is veel belangrijker dat de programmeur beschermd wordt tegen de fouten van zichzelf ; met de controle, dat hij anderen gehinderd heeft, is hij zelf heel weinig gebaat, zolang hij nog onbedoeld zijn programma kan hebben overschreven, in zijn getallenmateriaal kan springen etc. Indien van elke geheugenselectie vaststaat, dat hij heeft plaatsgevonden binnen de (deel)informatie-eenheid in kwestie, impliceert dit a fortiori, dat de programmeur anderen niet gehinderd heeft en de ingebouwde geheugenbescherming, die zich beperkt to uitsluiting van interferentie tussen programma's, komt niet eens meer aan bod. Het feit, dat de "Protection Feature" facultatief is, is voor mij, gezien de repercussies van zijn aanwezigheid (nl. niet meer homogeen geheugen) een groot raadsel.

ad 5) "Schijven-geheugen van grote capaciteit".

Behalve de opmerking, dat de combinatie van capaciteit, nog gehaalde accesstijden en prijs mij treft als een indrukwekkende prestatie, geen commentaar.

ad 6) "automatische correctie van tijdelijk machinefouten".

Dit suggereert mij, dat de machine incidentele fouten automatisch corrigeert, en wel allemaal, feilloos en onder alle omstandigheden. Als dit waar zou zijn, ben ik benieuwd te vernemen, hoe dit in zijn werk gaat. Ik kan het me nl. bv. moeilijk voorstellen welke correctieprocedure zonder speciale voorzorgen in de programma's in staat is de juiste waarde van een willekeurige byte te reconstrueren, wanneer deze abusievelijk onjuiste pariteit zou blijken te bezitten. Bij een lezing over de IBM 360 kreeg ik veel meer de indruk, dat hier in de eerste plaats sprake was van een diagnostisch hulpmiddel bij de localisatie van fouten en dat slechts in bijzondere omstandigheden correctie mogelijk is. Voorts spreekt de mij ter beschikking staande documentatie wel over pariteitsbits, maar bv. nergens over een zichzelf controlerende arithmetiek. Als inderdaad feilloze correctie van alle enkelvoudig optredende tijdelijke machinefouten niet onder alle omstandigheden gegarandeerd kan worden, moet ik U verzoeken de mogelijkheden van de zg. "machine check" iets genuanceerder te omschrijven.

ad 7) "mogelijkheid van programma herplaatsing".

Het betreft hier de weinig interessante mogelijkheid de definitieve plaats van een programma pas te beslissen op het moment, dat het programma in het geheugen wordt opgenomen, zonder dat deze beslissing bijwerking van de adressen in de (binaire) programmatext vergt. Dit is alleen van interesse, wanneer men de binaire text, los van hun uitvoering, een zelfstandig bestaan laat leiden, dwz. wanneer men van "Load and Go" geen standaardpraktijk kan maken. Als dit zo is - en bij geruchte heb ik vernomen, dat in de begeleidende software het concept van geprecompileerde programma(gedeelte)s nog steeds is gehandhaafd - is dit een veeg teken ten aanzien van de (automatische) programmeerbaarheid van de machine (wat, gezien het grote aantal expliciet benoemde registers, minder een verrassing dan wel een bevestiging van een reeds gekoesterd bang vermoeden is).

Veel erger is, dat datgene, dat met "mogelijkheid van programma herplaatsing" wel gesuggereerd wordt en in multiprogrammering absoluut noodzakelijk is, wil men het kerngeheugen enigermate efficient gebruiken, in de IBM 360 in het algemeen niet mogelijk is : is eenmaal de plaats, die een programma en zijn onderdelen in het kerngeheugen zullen innemen, gekozen, dan is tijdens de uitvoering van dit programma deze keuze niet meer herroepbaar. Door dit ernstig gebrek aan flexibiliteit - dat o.a. impliceert, dat bij elk programma van te voren een majorant opgegeven moet worden van de maximale geheugenbehoefte, zoals die in de loop van de uitvoering misschien maar even optreedt - krijgt men de hele rompslomp van "job scheduling" (en waarschijnlijk ook van segmentering) weer opgedrongen en gaat een belangrijk deel van de potentiele charmes van multiprogrammering verloren. De IBM 360 presenteert zich in dit opzicht als een uiterst conventionele machine met alle nadelen van dien.

ad 8) "relatief lage prijs".

Als - dankzij de revolutionaire fabricagetechnieken - de prijs in verhouding tot "het informatieverwerkend vermogen" vergeleken bij vroeger inderdaad significant gedaald is, dan geeft dit ernstig te denken. Tot voor kort beschreef de afdeling der electrotechniek haar behoeften in termen van een (conventioneel) geconstrueerde machine van circa f500 000,--. Nu doet zij plotseling het voorstel tot aanschaffing van een machine, die meer dan anderhalf maal zo duur is, en bovendien relatief goedkoop zou zijn. Over deze plotselinge, zeg, verdubbeling van de behoefte aan beschikking over digitale apparatuur rept het voorstel met geen woord, hoewel dit voor een ieder, die enigszins met de voorgeschiedenis op de hoogte is, toch wel een vreemde zaak moet zijn.

Ten aanzien van de in sectie 3 van het voorstel opgesomde toepassingsgebieden zou ik het volgende willen opmerken. Over de aard en omvang van de hieruit voortvloeiende machinebelasting is - althans voor een buitenstaander als ik - moeilijk een beeld te vormen ; het wordt daardoor weinig duidelijk, dat de machine, die de THE reeds in bestelling heeft, niet als het hiervoor aangewezen stuk gereedschap beschouwd moet worden. De indruk van de toepasbaarheid van deze laatste machine wordt nl. door de "lofzang" alleen nog maar versterkt.

Tenslotte : een in dit voorstel slechts terloops genoemde faciliteit, nl. de drijvende komma faciliteit, vraagt wel om enig commentaar.

1. Door de krapte aan bits in de enkelwoords drijvende arithmetiek is deze nauwelijks interessant : er is een compromis uit de bus gekomen, waarin zowel het bereik, als de relatieve preciesie nog kleiner zijn dan bv. in de IBM 1620.

2. Zodra men op dubbele lengte overgaat komen alle bits van het tweede woord aan de mantisse ten goede, maaar het te kleine exponentbereik blijft onverminderd als bezwaar kleven.

3. De representatie van de drijvende getallen is zo gekozen, dat de uitwerking van de transferfuncties van en naar vaste komma representatie (vooral in de ene richting) nodeloos ingewikkeld zijn.

4. Een en ander wordt nog versterkt, doordat de communicatie tussen de registers met drijvende en die met vaste komma slechts via het geheugen mogelijk is.

5. Met het oog op de byte-scandering hebben de ontwerpers zich laten verleiden, om de exponent op basis 16 te betrekken. Hierdoor fluctueert de relatieve prciesie, waarmee getallen gerepresenteerd kunnen worden, een factor 16. Een van de grootste voordelen van de drijvende binaire komma (waar deze fluctuatie slechts een factor 2 is) is hiermee verloren gegaan. Het numerieke ongerief van de drijvende decimale komma is in de IBM 360 dus nog een keer versterkt !

6. De opdrachtcode bevat opdrachten, die hun drijvende resultaat niet "nanormeren". Indien deze ingevoerd zijn in de gedachte, dat hiermee een preciesiecontrole kan worden uitgevoerd, dan berust dit op een vergissing (zie bv. Wilkinson). Indien zij ingevoerd zijn met snelheidswinst als oogmerk (de niet na-normerende opdrachten kunnen nl. sneller uitgevoerd worden), dan hebben de ontwerpers zich hier "pound foolish and penny wise" betoond. De non-unieke getalvoorstelling zal elders nl. een aanzienlijke prijs vergen : in de drijvende arithmetiek, die nu ook ongenormeerde getallen als operand moet accepteren - deze prijs kan klein zijn - maar zeker, doordat de kans op prgrammafouten hierdoor aanzienlijk gestegen is.

7. De arithmische bewerkingen op drijvende getallen leveren niet een fatsoenlijk afgerond resultaat, maar een domweg afgekapt. 8. Doordat negatieve getallen in het zg. tweecomplementensysteem gerepresenteerd worden, leidt dit afkappen voor positieve getallen tot verkleining, voor negatieve getalen tot vergroting van de absolute waarde. Elementaire relaties als

- (a * b) = (-a) * b

zijn in deze onreine arithmetiek dus niet meer gewaarborgd. Over de commutatieviteit van de vermenigvuldiging en de optelling zwijgt de documentatie......

Kortom, de drijvende arithmetiek van de IBM 360 is een sprekend voorbeeld van het soort wanproduct, dat een ongebreideld opportunisme pleegt voort te brengen.

Dit, waarde collega, was mijn commentaar op het voorstel. De tijd heeft mij ontbroken om kort te zijn ; voor de lengte van dit commentaar bied ik mijn verontschuldigingen aan.

Met collegiale groeten,
Uw





E.W.Dijkstra


transcribed by Sam Samshuijzen
revised Sun, 19 Dec 2004