SARA - SAABs RäkneAutomat av Sven Yngvell inknappat av Pär Ernanuelsson Jag ska tala lite grann om SARA, Linköpings försu dator. En kommenur till det Viggo sade; han ulade om krisdden, då hade vi bröd på kort och kött på kon. Numera har vi datorer på kort så det är ju ingen stöm skillnad. :-) Nu slumpar det sig faktiskt så att SARA nu fyller 100.000 år, samtidigt som Lysator fyller 10.000 år, så det är ju en lämplig tid- punkt. SARA står för SAABs RäkneAutomat. Och vid den tidpunkten, 1957 och tidigare, var ju inte nomenklaturen på det här området fastställd, uun det man hade framförallt var benämningen "matematikmaskin" - de försu datorerna i Sverige gjordes ju av Matematik- maskinnämnden i Stockholrn. Sedan ular man om daumaskiner och datorer. Jag har för mig att det var Börje Langefors som var pap- pa till odret "dator" och han var också pappa till SARA. SARA utvecklades på avdelnin- gen för numerisk analys på SAAB där Börje Langefors var chef. Bo Ragnemalm här job- bade med elektroniken; själv är jag inte elek- troniker uun jobbade med programvara på SARA. Ett skäl till att SAAB gav sig in på det här området är ju att utvekcligen av flyg kräver datorresurser, vilket inte mninst illustreras av att datorerna ibland inte räcker och planet faller ner. Det här är ju egentligen den senaste utvecklingen på SAAB, där vi har en superdator av typ CRAY-I. Nu råkar det vara så att CRAY-I gjorde sin sista arbetsdag i går och håller i dag på att monteras ner, så CRAY-I är alltså också historia i dag och passar kanske därför in i Lysators annaler på något sätt... Dessförinnan använde vi ju D21 och D22 för utveckling av 37:an (Viggen) och tidigare hade vi vår kära SARA, som användes till utvecklingen av Draken i stor utsträckning. Draken var ju inte SAABs fdrsta flygplan och man kan då fråga sig hur utvecklingen av de tidigare flygplanen gick till. Här visas någon typ av utrustning. Det är en hålkortsdriven elektromekanisk kalkylator, som var det man hade, samt räknestickor och bordskalkylator- er. Jag var själv inte med på den tiden, utan Bosse och jag bdrjade 1956 och då hade mar kommit en bit på väg med utvecklingen a~ SARA. När man skulle utveckla SARA var det så att det redan fanns en dator i Sverige som hette BESK, utvecklad av Matematikmaskin- nämnden. Man var ute i världen och tittade om man kunde köpa datorer, men det fanns egentligen ingenting att köpa vid den tid- punknten. Så vad man ~orde var att man köpte BESKs konstruktion. Men eftersom BESK var den första datom så fanns det naturligtvis vissa saker som inte var så bra gjorda och då modiflerade man BESK. Det här gjorde att SARA blev inkompatibel med BESK, vilket ni känner igen från dagens da- torbranch. Ordet "kompatibilitet" var ju knappt uppfunnet på den tiden så det var inget starkt krav. Det fanns ju inte nån våldsamt stor programvarumängd till BESK, inga stan- dardsystem som kunde Iyftas in. De program- men som gjordes anpassades väldigt strikt till datorn. För den skull gjordes en utveckling från BESK, som gick efter två linjer. Från början var det så att Regnecentralen i Köpenhamn också köpte samma konstruktion som vi på SAAB, så operationsregister och liknande saker var identiska på DASK och SARA. Men de skulle ha indexregister och det skulle ju inte vi ha, så vi uppnådde snabbt inkompat- ibilitet här också. BESK, däremot, utveck- lades ju vidare i FACIT EDB genom att hela gänget från Matematikmaskinnämnden köptes över av Åtvidabergsindustrier och senare blev FACIT och FACIT EDB. En reservation först; det som jag pratar om här är sånt som jag har letat upp i papper och i minnet och det är ju inte riktigt tillförl- itligt även om minnet var fräschare för 32 år sedan så är det ju inte säkert att det stämmer riktigt, så jag måste reservera mig lite mot att jag minns fel. Om vi tittar på SARAs uppbyggnad så hade den en styrenhet, ett kärnminne, en räkneenhet, i vilken det fanns ett ackumula- torregister. Inmatning gick via hålremsa; ut- matning via hålremsa eller en konsolskriv- maskin. Det fanns ett trumminne och så småningom också ett magnetbandssystem som kallades för SARAband. Överföringama från kärnminnet ner till räkneenheten var par- allella, medan övriga överföringar var seriel- la. Jag har ritat ut ackumulatorregistret för det var väldigt centralt i maskinen; allt som mat- ades in och ut gick genom ackumulatorregis- tret. Så man kunde inte ha något stående i ac- kumulatomgistret och göra nån extem aktiv- itet, för då var det förstört. Mycket av de här komponenterna var hembyggen fdr det fanns inte. Tag trummin- net t.ex. Man fick låta en verkstad svarva en trumma som man sedan belade med ett mag- netiskt skikt. När det gäller kärnminne köpte man en massa kämor som man provade och sedan sydde man ihop dem. Det var alltså inte så trivialt. Viggo: Ursäkta Sven, men du sa att du kunde ha minnesluckor. Det är faktiskt så att du har glömt en väsentlig enhet. Det var näm- ligen så att hålremsa spelade en central roll och efter an man har läst hålremsorna måste de fångas upp och det skulle man ju ha pap- perskorgar till förstås. Så gruppen kring SARA gick in med en anhållan att köpa några papperskorgar. Och då hamnade ärendet i SAABs byråkrati fdr kontorsmateriel vilket medförde att ärendet fördröjdes och sedan avslogs. Det ansågs inte tillräckligt motiverat mod papperskorgar. Då var det nåt Ijushuvud som kom på att man kunde skriva en anhållan om inköp om behållare för informationsrem- sor. Och det gick utmärkt! Sven Y: Helt rätt. Det var en mycket väsentlig komponent och historien är ingen efterkonstruktion. Ordlängden på SARA var som för BESK: 40 bitar. Och det var två instruktioner per ord, dvs instruktionslängden var 20 bitar. Kärn- minnet på var på 2048 ord. Om vi tittar på BESK som var föregångaren så använde de ett Williamsminne, dvs ett katodstråleminne och ursprungligen på 512 ord, senare 1024 ord. Man kunde alltså se hela minnesinnehål- let och när man programmerade så &nns det restriktioner på cyklernas storlek. Om man hade en cykel på bara tre instruktioner så växte den binära fläcken och påverkade de omkringliggande bitarna. Jag har för mig att man därför måste ha minst sex instruktioner i en cykel för att inte en störning skulle uppstå. Klockperioden var 14 eller 28 mik- rosekunder tror jag. Additionstiden var 56 mikrosekunder och jag har för mig att det var fyra klockcykler för en addition, dvs klock- cykeln var nog 14 mikrosekunder. Trummin- net var fysiskt två trummor och det hade 256 kanaler a' 32 ord. Så man gav adressen till en kanal och läste sedan de här 32 orden. Och med den här rotadonshasdgheten får man 20 mnillisekunders rotadonsdd och medelac- cessdden blir då ungeför 30 millisekunder. I princip hade man alltså en accessdd på I ms per ord. Trumminnet var sådant an man inte kunde lita på an man kunde lagra nåndng där när datorn stängdes av, utan i samband med kömingen använde man mninnet men man kundc inte ha något permanent lagrat där. Minnesutrymmet var också så begränsat att man inte kunde räkna med att få ockupera specidlt mycket. SARAband var se~c bandaggregat som köptes från AMPEX i USA och det påstås an vi var de första i världen som hade digitala bandaggregat dll en dator och vi hade mycket besök dll Linköping som skulle dtta på mag- netbanden. Det lusdga var att de här magnet- banden fungerade väldigt bra från början. Det var väldigt lite inkömingsp~blem alltså. De hade en fast Ibocklängd på 64 och framför varje block hade man ett nummer, från 1, 2, 3, och så vidare. Packningstätheten var 300 bitar per tum och bandhastigheten var 60 tum per sekund. Man hade skrämt upp den här bandspelaren dll dubbel hastighet mot vad den ursprungligen var specificerad för. Ban- det var 3/4" brett och innehöll sju kanaler på viUka man hade enbitskorrigering och tvåbits- detektering och det var antagligen det som gjorde att det fungerade så bra. Teoretiskt låg alltså datahastigheten på 18.000 tecken per sekund, men genom att man fick ha stora blockmellanrum så skuUe jag gissa att den praktiska hastigheten gick ner till hälften till kanske 9.000 tecken per sekund som den praktiska hastigheten. Men genom att man hade förinskrivna blocknummer så kunde man programmera datom så att den letade upp block på bandet. Man kunde förutse att "då och då behöver jag det blocket" och då kunde den leta upp blocket autonomt i fdrhål- landet till datorn i övrigt, så det stoppade inte upp. I övrigt var det så att när man beordrade en operation så stoppade ALLT upp till oper- ationen var slutförd. Man kunde t.ex. inte beräkna och läsa trumminnet samtidigt. Men när det gällde magnctband kunde man alltså göra det parallellt, vilket gjorde att rnan med lite smart programmering kunde få upp hastigheten. Bl.a. matrismultiplikation körde vi mycket ihop från två bandstationer och ut på en annan; det var mycket pyssel med det. Input var alltså femkanals hålremsa. I början hade vi en Ferranti remsläsare som läste 200 siffror per sekund, rnen så smanin- gom kom FAClTs snabbläsare med 400 sif- fror per sekund. Den där halremsan var ingen telexremsa. För det första använde vi hexa- docimal, ja vi sade sedecimal på 1800-talet, representation och i princip var det det som avspeglades på remsan. Här är ett exempel pa en remsa. Den här stansningen här betydde att nästa tecken är ett sedecimalt tecken. Det här är 8 plus 4 plus 2 vilket blir ... C? Ja, ni kan- ske inte är så hemma på det numera. Men var det inte stansat här så betydde det ty- pografiskt tecken. Det kunde t.ex. vara mel- lanslag som användes när man skulle skriva ut remsan, men typografisk information lästes aldrig in i datorn. Vi hade alltså egent- ligen ingen chans att läsa en telexremsa. Som output kunde vi emellertid stansa även ty- pografiska tecken vilket g~orde att vi kunde göra en telexremsa och det giorde vi också vid några ullfällen så att vi kunde skicka vi- dare data via telex. Man kan säga att det var vår första datakommunikation.programmera Som output hade vi en skrivmaskin. Som ni ser var IBM redan med på den här tiden. De hade en vanlig skrivmaskin med vagn, men den var väldigt robust. Den tog 12-15 tecken per sekund och den gick i ett. Det var det bäs- ta vi hade. Sedan hade vi från början en hål- remsstans som stansade 25 tecken per sekund. Och det kan ni ju tänka er att det krävdes tålamod alt göra en minnesdump. Så småningom fick vi en FACIT snabbstans på 150 tecken per sekund. Jag vet inte om det gjordes nån snabbare i världen. Vi var väldigt duktiga på hålremsutrustning i Sverige, eller i Norden. Vi var också duktiga på att "pro- grammera" användningen av hålremsutrust- ning. Ofta, om man tittar på det internation- ellt, så var det så att man använde hålremsa som en sorts hålkort. Man avbildade hålkorts- funktioner på hålremsa. Men vi hade registre- ringsutrustning från FACIT. Man kan t.ex. sätta i den ena hålremsan här, så får man en kopia i den andra. Och man kunde köra au- tomatiskt fram till ett ställe och sedan stegvis om man ville rätta ett tecken. Eftersom man hade sina program på hålremsa som var väl- digt långa så var det ändå jobbigt att rätta och då hade man en konduktörstång och tejp, för enkla ändringar. En sak ska också påpekas. De här utrust- ningarna var ganska otillförlitliga, dvs om man kopierade en remsa var man inte säker på att kopian var likadan. Så det var obliga- toriskt att man tog sina remsor och jämforde dem mot Ijuset. En checksumma fanns det också sist på bandet om det var något värde- fullt som lagrades. Det här är en skiss över räkneenheten. Vi hade ett multiplikandregister som användes så att data från minnet gick ner till det regis- tret och sedan adderade det till ackumulator- registret. Additionstiden var alltså 56 mik- rosekunder. När det gäller multiplikation satte man ena multiplikatorn i multiplikator- registret och sedan multiplicerade man med något från minnet och resultatet hamnade of- tast i ackumulatom. Division tog lika lång tid och då hade man innehållet i ackumulatom och dividerade det med innehållet i ett minne och då fick man svaret i multiplikatorregistret och resten i ackumulatorn. ~a, jag menar att division tog lika lång tid som multiplikation och det var 364 mikrosekunder. En av de fdr- bättringama vi införde jämfort med BESK var att divisionen på BESK gav kvoten bakvänt i ett register och man var tvungen an g6ra en operation som vände kvoten. Det ville vi inte ha, utan vi gjorde så vi fick rät- tvänt svar. Då kommer vi in på hur det hela ser ut in- struktionsmässigt. Som jag sade var instruk- tionen 20 bitar varav 12 bitar var adressen och operationen var 8 bitar. Det gjorde att man kunde adressera 4096 och eftersom vi hade 2048 ord i minnet så kunde vi adressera halvord i minnet. Så en jämn adress var en vänsterhalvord (20 bitar) och en udda adress var ett högerhalvord. Operationslistan hade egentligen en grundform som endast var på S bitar, där exempelvis addition hette 00 och subtraktion 01 etc och de jobbade på helord (40 bitar). Om man däremot lade till en etta på operationens grundform innebar det att operationerna jobbade på halvord. Det är all- tså sex bitar. Går vi fram till sju bitar så inne- bar det att man nollställde ackumulatorregis- tret och adderade in resultatet till ackumula- torn. Den åttonde biten hette E2-biten, av någon anledning. Hade man en etta där inne- bar det att instruktionen utfördes precis som vanligt, men ett vred på konsolen kunde då påverka exekveringen så att man kunde köra programmet stegvis och man fick då alla in- struktioner och registren utskrivna på kon- solen och den gick så den glödde. Debugging kallas sånt i dag och det var detta tillsammans med en minnesdump som var de felsökn- ingsmöjligheter som fanns. När det gäller aritmetiken så var det fast binärpunkt som låg mellan position noll och ett så i princip låg talen mellan -I och +1. Programvara Programmen skrevs i absolut form och gjorde man ett fel blev det jobbigt till max. Nu är det ju så att man inte kan skriva allt från grunden utan det finns standardrutiner som man gärna ville ha med i sitt program. Dessa program låg i s.k. 800-form. Det betydde att man skrev ett program så att det började på adress 800 (halva minnet) och uppåt. Det man ~ orde sedan var att man hade sina progran- på halremsa och matade in. Skulle man ha in några standardprogram, t.ex. sinus, så stop- pade man in den remsan först. Man hade se- dan en automatisk ändring av adresserna så att det skulle stämma. En del operationer hal ju inte adress, t.ex: skiftinstruktioner, men de har ju inga skift på 800 så det kunde man de- tektera an man inte skulle ändra på. Man val också tvungen att tala om hur långa rutinerna var, för i slutet på remsoma kunde det ju ko- mma godtyckliga konstanter och sånt och de skulle ju inte ändras även om de var större än 800. Men om man sedan ändrade sina pr~ gram, t.ex. Iade till tre rader, var man tvungen att uppdatera sina program så att grunda- dressema blev rätt. Man kom ju underfund med an det här var väldigt jobbigt; programmen blev ju aldrig rättade. Därför hade man på BESK infört ett system som hette FA5 (ja, det fanns nåt som hette FA4 också och förmodligen FAI även om jag inte vet vad det är). Vi kopierade iden till SARA och det innebar i princip att när man skrev sitt program skrev man inte abso- lutadresser, utan om man skulle hoppa någonstans i sitt program så satte man en la- bel där. Lablarna lästes sedan in och över- sattes automatiskt och standardrutinerna kun- de också få lablar. Längre fram utvecklade vi någon sorts "auto code" med flytande räkn- ing, men det gick så långsamt så man vågade inte använda den. Men vi hade alltså möjlighet att skriva de aritmetiska instruk- tionerna direkt. Väldigt mycket av det som sen kom till D21 och DAC var alltså erfaren- heter från SARA. Vi hade ju fått väldigt stor erfarenhet att skriva a~l programvara från grunden vilket var väldigt betydelsefullt för D21. Själv kom jag med i Viggos gäng på D2 I på programvarusidan så smaningom. Jag ska avsluta med en annan episod. 1958 kom tidskriften Datamation på besök och ~orde en artikel. Många bilder på SARA och givetvis var de tvungna att skriva "Sur- rounded by IBM and Creed equipment" som bildtext. Vi hade ju förstås en högtalare pl SARA (liksom på BESK) och som avslutnin på artikeln var det en minnesdump på "Th~ Swedish song Oxdragarsången by Ever Taube". En av de första sakerna vid inkörnin gen av SARA vat att se till att högtalare fungerade. Jag skrev ett program så att v kunde generera musik och det hade vi väldig stor glädje av vid inkörningen. Man testad~ nämligen morgonkonditionen på så sätt at om SARA spelade falskt sal var det nalt fel p~ maskinen. Mycket nyttigt. Högtalare var j~ för övrigt ett mycket nyttigt hjälpmedel ända in på 70-talet och fanns det inte högtalare s~ kunde man sätta på en radio och få in störnin- gar på FM-bandet. Operatörer kunde sitta och dricka kaffe och de kunde direkt höra i högta- laren om det blev nåt fel.