Compiler-gruppen: Teknisk perfektionisme kontra nytte - 2

I en alder af 22 år fik jeg min kandidatgrad (1965), selvom jeg havde brugt det meste at tiden på at arbejde hos RC. Jeg følte luften under vingerne og bad om at blive overflyttet til den mest prestige-fyldte afdeling, compiler-gruppen. Forinden havde jeg sat mig grundigt ind i Algol compilerens opbygning.

Det var fantastisk at komme ind i compiler-gruppen. Man sad ikke alene og nørklede, men alle fulgte med i hvad de andre gjorde. Peter Naur og Jørn Jensen var de ubestridte guruer, og de havde fastlagt gode principper for hvordan man testede, dokumenterede koden, osv.

Min første opgave var at dokumentere assembler-koden til passage 7 af Gier Algol 3 compileren, som nylig var blevet frigivet. Det geniale princip i compileren var at den bestod af 8 passager, som hver læste hele kildeprogrammet igennem og leverede det videre til næste passage i en mere hensigtsmæssig form. På den måde kunne man oversætte selv meget store programmer lynhurtigt, selvom maskinen kun havde 5 k memory, som det ville hedde i dag.

Passage 6 havde omformet alle udtryk til omvendt polsk form og kontrolleret at operander typemæssigt passede med operatorerne. Passage 7 dannede nu en forkortet form af maskinkoden ud fra passage 6's resultater. Endelig udvidede passage 8 den forkortede maskinkode til den fulde form. Naur havde skrevet passage 6, og koden var eksemplarisk kommenteret. Passage 7, derimod, var skrevet af Jørn under tidspres, og den var stort set helt uden kommentarer. (Det er jo ikke altid en guru tager sin egen medicin).

Når man betænker at der ikke var symbolske adresser i assembleren, men kun labels af formen a1, a2 ... k1, k2 ..., så er det utroligt at man overhovedet kunne forstå hvad der skete. Nå, men det lykkedes mig at kommentere alle 700 kodelinier til alles tilfredshed. Set i bakspejlet var det en ganske glimrende svendeprøve.

En fantastisk ting ved compileren var, at den til forskel fra datidige compilere fortsatte med at oversætte når den havde fundet en fejl i kildeprogrammet. Men som menig bruger af den havde jeg været irriteret over dens fejludskrifter. Hver af passagerne udskrev nemlig de fejl den selv fandt. Udskriften bestod af et linienummer i kildeteksten og en meddelelse om fejlens art. Når man oversatte et større program, kunne der godt være 100 fejl som man skulle finde frem til i kildeteksten. Først bladede man hele teksten igennem for at lokalisere de fejl som passage 1 havde fundet, så en gang til for at finde passage 2's fejl, osv.

Jeg spurgte Jørn hvorfor hver passage ikke bare sendte fejlangivelserne videre til næste passage. Så kunne passage 6 udskrive dem alle sammen i linienummer-orden. Så sparede man også lidt plads til at generere udskrifter i hver af de første passager. Jørn kiggede overrasket på mig og bragte ideen videre til Naur.

Næste gang jeg så Naur var han meget rosende og fortalte mig at det var den slags ideer man satte højt. Enkle, nyttige og robuste (under robust hører bl.a. at løsningen også kan klare usædvanlige situationer). Disse principper blev et ideal der ledte mig i mange år fremover, indtil det gik op for mig at det var en frygtelig grøft man var havnet i. Mere om det nedenfor.

I de følgende år kom jeg til at deltage i mange af compiler-gruppens projekter. Algol 4 til Gier, Algol 5 og 6 til RC 4000, og operativsystemerne til RC 4000. Der var masser af udfordringer og masser af succeser - i hvert fald målt med vores egen målestok.

På et tidligt tidspunkt fik Bech og Naur den idé at jeg skulle dele kontor med Naur, en ære der var uhørt på RC. Det blev en meget lærerig periode. Jeg kom fra en ganske almindelig familie hvor kun en moster var blevet student, og slet ingen vidste hvad en akademisk uddannelse var. Så der var mange ting på mange niveauer jeg skulle lære.

En af dem var at tænke lige som Naur. Det foregik på en skrivemaskine, hvor Naurs tanker kom lige så smukt og velstruktureret ud af hans hænder og ned på papiret. De få ting der skulle ændres, klarede han bagefter med saks og klisterbånd. Jeg prøvede ihærdigt i over et år, men mine tanker var åbenbart af en anden art, for de kom altid hulter til bulter og ville slet ikke rette sig ind.

Til sidst opgav jeg og gjorde som jeg plejede, først tegninger på tavlen, så en disposition med mange udviskninger og streger, så et skitsemæssigt manuskript, og så renskrift. Men jeg var alligevel blevet meget bedre til at skrive under Naurs hånd, især formulere mig kort og præcist. Med tekstbehandling kan jeg i dag næsten gøre som Naur: få tankerne pænt ned på skærmen i første hug (næsten).

Jørn og Naur prægede også min åndelige udvikling på mange andre områder. Vi kunne diskutere alverdens ting indenfor naturvidenskab og filosofi, og de anbefalede mig at læse Scientific American, hvilket jeg har gjort siden.

Jørn og jeg var dog mest optaget af computeren, og vi vidste i detaljer hvad der foregik helt inde i den. Her er et lille eksempel. RC var involveret i alle folketingsvalg. RC registrerede alle valgtallene efterhånden som de ankom til Indenrigsministeriet, og computeren talte op og beregnede prognoser. Resultaterne gik direkte på skærmen, mere og mere elektronisk efterhånden som årene gik.

Ved folketingsvalget i 1966 gik det galt. Valgstudiet var sat op i Falkonércentret, og Uffe Ellemann Jensen var TV-journalist. Under en af prøverne interviewede han en stumtjener i garderoben, og hver gang han havde stillet "politikeren" et spørgsmål, trådte han over på "politikerens" plads og besvarede spørgsmålet fuldkommen som denne politiker ville have gjort. Alle i studiet lå flade af grin under disse seancer.

Nå, til sagen. Compiler-gruppen havde ikke lavet valgprogrammerne. De var lavet i Algol af andre, men Jørn og jeg var med ved Gier computeren i studiet, hvis nu noget skulle gå galt.

Og det gjorde det.

Da de sidste valgtal var blevet registreret, skulle computeren straks skrive landsresultatet ud, men intet skete. TV-producerne blev nervøse og måtte holde seerne hen, og de der kendte valgprogrammerne gik i gang med at finde fejlen. Christian Gram sørgede for at alle fik arbejdsro, og efter en halv time var fejlen fundet. En rettelse foretaget i sidste øjeblik var ikke blevet testet ordentligt. Programmets centrale løkke blev afsluttet når antallet af resterende valgkredse, n, var nede på 0, og så kom valgresultatet. Men rettelsen havde bevirket at når sidste kredsresultat kom, blev n ikke talt ned fra 1 til 0. Programmet kørte derfor rundt i en evig løkke.

I princippet var det let at klare. Programmet skulle bare rettes lidt og oversættes. Men det ville desværre slette alle kredsresultaterne, så de måtte indlæses igen. Skønsmæssigt ville det tage et par timer og det kunne let gå galt. Jørn og jeg blev sat ind i sagen. Vi konfererede kort med hinanden og blev enige om at vi kunne rette n direkte i lageret mens programmet kørte. Med vores kendskab til compileren kunne vi regne ud hvilken lagercelle n lå i. Vi satte computeren på pause og sammen med Knud Bruun fra Præstø, kiggede vi via teknikerpanelet på celle 853 (eller hvad det nu var). Der skulle n være.

Ganske rigtigt, der var et ettal. Vi kontrollerede lige nabocellerne for at se at det var det rigtige ettal vi havde fundet. Okay. Så ændrede vi cellen til nul. Det var ikke et almindeligt heltalsnul, men et flydende nul, så det skulle gøres med omhu. Det hele tog vel højst 10 minutter. En sidste kontrol - og med stor spænding trykkede vi på kør. Jubi! ud kom landsresultatet.

2 af 5. Trykt i Dansk Datahistorisk Forenings festskrift, 2005: Regnecentralen - dansk institut for matematikmaskiner. Gengivet med tilladelse af redaktørerne Henning Isaksson og Ole Pedersen.

Søren Lauesens billede

Kommentarer (5)

Troels Henriksen

Lavede Algol-oversætteren nogen optimeringer? Jeg har læst artiklen om den oprindelige FORTRAN-oversætter, og så vidt jeg husker nævner de CSE og constant-folding. Jeg husker dog også noget mere end de otte passager Algol-oversætteren består af, og sikkert bygget til en større maskine. Det ville IBM jo tjene på!

Søren Lauesen

RC's Algol oversætter lavede en del optimering, bl.a. optimeret brug af hardware-registrene. Den oversatte direkte til binær kode, mens andre på det tidspunkt genererede assembler-tekster. Det kørende program brugte virtuelt lager, ellers ville der ikke kunne køre lange programmer. Desværre bevirkede det at lange programmer let blev meget langsomme.
NIM-simulatoren blev skrevet i assembler. Der var hverken lagerplads eller bit-operationer nok til at bruge Algol.

Torben Mogensen Blogger

Såvidt jeg ved (efter at have skimmet Naurs "The Design of the GIER ALGOL 60 Compiler") er der ikke lavet egentlige optimeringer. Naur skriver om performance, at han ikke betragter det som særligt interessant at sammenligne køretider for oversatte ALGOL programmer og håndskrevne maskinkodeprogrammer: "Even if a well-defined comparison can be made the outcome of it is of no particular interest because it does not point to constructive improvements of the design." Han nævner dog, at specielt indicering i arrays er langsom og foreslår, at særlige instruktioner til dette tilføjes GIER.

Log ind eller opret en konto for at skrive kommentarer