Statiskt analysprogram för Rapid - Mälardalens högskola

Mälardalens högskola Eskilstuna/Västerås 2008-04-30 

Statiskt analysprogram för Rapid 

Student: Harald Lögdahl 

Examinator: Professor Björn Lisper 

Projektledare: Ingemar Reyier 

1

SAMMANFATTNING 

Denna rapport redogör för ett examensarbete på D-nivå på uppdrag av ABB Robotics i 

Västerås. Det går ut på att konstruera ett verktyg för att upptäcka problematiska egenskaper 

och programkonstruktioner i ABB:s interna programspråk för robotar, Rapid. Dessa 

egenskaper efter kom efterhand att begränsa sig till att bli användning av oinitierade variabler 

och kommandon som försätter Rapidprogrammen i vänteläge, när en händelse, som i Rapid 

heter Trap, är den som utlöst detta. Detta verktyg, eller program, måste förstå Rapid ungefär 

på samma sätt som en kompilator, samt dessutom kunna analysera fram olika möjliga 

programflöden och vad som händer i dessa. 

Verktyget visade sig fullt möjligt att utveckla, metoden för detta är densamma som för 

motsvarande statiska analysverktyg för andra mer spridda programspråk. 

2

INNEHÅLLSFÖRTECKNING 

SAMMANFATTNING .............................................................................................................. 2 

INNEHÅLLSFÖRTECKNING ................................................................................................ 3 

INLEDNING .............................................................................................................................. 5 

Statiskt analysprogram för Rapid.......................................................................................... 6 

1. Motivering......................................................................................................................... 6 

1.1 Programanalys av intressanta egenskaper i Rapid............................................. 6 

1.2 Inte bara en kompilator behövs .............................................................................. 6 

1.3 Skal ............................................................................................................................. 6 

1.4 Waitstate - Definering ............................................................................................. 6 

1.5 Tidsbestämning i programmet............................................................................... 6 

1.6 När är waitstate intressant...................................................................................... 7 

1.7 Oinitierade variabler - Risker ................................................................................. 7 

2. Rapid................................................................................................................................. 8 

2.1 Användningsområde ................................................................................................ 8 

2.2 Moduler och TASK:s ................................................................................................ 8 

2.3 Datatyper i Rapid ...................................................................................................... 9 

2.4 Kommandon i Rapid............................................................................................... 10 

2.5 Goto .......................................................................................................................... 14 

2.6 Trapar ....................................................................................................................... 14 

2.7 Filstruktur i Rapid .................................................................................................... 15 

3. Analys ............................................................................................................................. 16 

3.1 Programflöden......................................................................................................... 16 

3.2 Programflöden i Rapid ........................................................................................... 17 

3.3 Waitstate .................................................................................................................. 19 

3.4 Programflödesekvationer avseende initiering av variabler .............................. 20 

3.5 Oinitierade variabler, parametrar och recordar.................................................. 22 

4. Metod .............................................................................................................................. 25 

4.1 Programflödesanalys av Rapidprogram och huvudbegrepp ........................... 25 

4.2 Lexikal analys .......................................................................................................... 25 

4.3 AST och noder – en generell beskrivning........................................................... 25 

4.4 AST och noder för Rapid analysprogrammet..................................................... 25 

4.5 Traversera noder, analysalgoritm ........................................................................ 29 

4.6 Traversering av AST i analysprogrammet .......................................................... 31 

5. Lösning - Parser ............................................................................................................ 33 

5.1 Inledning................................................................................................................... 33 

5.2 Verktyg...................................................................................................................... 33 

5.3 AST från Parser ...................................................................................................... 37 

5.4 Analysprogrammet - Användning......................................................................... 38 

5.5 Analysprogrammet - Programmering .................................................................. 39 

5.6 Felmeddelanden och varningar............................................................................ 41 

5.7 Orsakskedjor............................................................................................................ 43 

5.8 Skal och vidareutveckling för andra uppgifter .................................................... 43 

6. Relaterat arbete............................................................................................................. 44 

6.1 Inledning................................................................................................................... 44 

6.2 Coverity..................................................................................................................... 44 

6.3 Klocwork................................................................................................................... 45 

6.4 Polyspace................................................................................................................. 46 

3

SLUTSATSER........................................................................................................................ 48 

REFERENSER....................................................................................................................... 49 

APPENDIX.............................................................................................................................. 50 

4

INLEDNING 

Målet med detta projekt är att skapa ett verktyg för att kontrollera att inte vissa allvarliga 

brister sker i programmeringen av Rapidprogram. Rapid är ABB:s interna programspråk för 

robotstyrning. Verktyget ska analysera Rapidkoden statiskt vilket är i motsats till att den körs 

och testas med olika indata. Slutmålet för ABB är ett generellt verktyg för analys av 

Rapidprogam men i det här examensarbetet valdes två egenskaper ut som testfall, att hitta 

användning av oinitierade variabler och att hitta väntekommandon om det är en trap som har 

exekverat dessa. Trap är motsvarande avbrott i andra programspråk. 

Analysverktyget måste likt en kompilator kunna förstå Rapidkoden samt att ta ut möjliga 

programflöden i denna. Till det tar det hjälp av att ett abstrakt syntaxträd, AST byggs upp. 

Det består av olika program noder, ett för varje kommando, samt att rutiner och moduler har 

egna noder. Moduler är i Rapid enheter som tillsammans läggs ihop till en körbar enhet. Det 

finns systemnära, oftast färdigprogrammerade moduler, och program-moduler som är 

specifika för själva Rapid applikationen, som också kallas task. Analysverktyget ska kunna 

analysera programflöden genom alla typer av rutiner och moduler. Analysverktygets uppgift är 

ytterst att bidra till bättre programmerade Rapidprogram. 

Programmet visade sig fullt möjligt att utveckla. Det körs som en exekverbar Java applikation 

där man väljer ut en specifik Rapidfil som ligger i ett Rapidprojekt, eller task. Det går att 

konfigurera beträffande vilka väntekommandon som kan vara riskabla samt hur lång tid man 

kan vänta på vissa av dessa. 

5

Statiskt analysprogram för Rapid 

1. Motivering 

1.1 Programanalys av intressanta egenskaper i Rapid 

Meningen med det här examensarbetet är att finna ett sätt att upptäcka intressanta egenskaper i 

Rapid-programmerade källkodsfiler. Rapid är ABB:s interna programspråk för 

robotprogrammering. Det handlar inte om syntaktiska fel utan om fel och brister som kan ge 

upphov till problem och oönskade effekter under programkörning. Efterhand blev det bestämt 

att de fel som bör upptäckas i Rapidprogrammen var att inte viloläge kan uppstå över en viss 

tid om en trap (se avsnitt 2.6) har beställts och exekverats, samt att inte oinitierade variabler 

används i t. ex tilldelningssatser på höger sida i uttrycket. 

1.2 Inte bara en kompilator behövs 

Eftersom det inte direkt är syntaktiska fel som eftersöks så är det inte en ytterligare 

Rapidkompilator som krävs för att lösa uppgiften. En kompilator i vanlig mening behöver 

inte, och ABB:s gör det inte heller, undersöka om en variabel som används är initierad 

tidigare. Den kollar inte heller om wait-kommandon körs när en trap har beställts eller 

undersöker några programflödesvägar (se avsnitt 3.1) utan kontrollerar bara att programmet är 

korrekt uppställt rent syntaktiskt. T. ex så måste variabeldeklarationer komma före 

rutindeklarationer i en modul eller en subrutin. Men det analysverktyg som kommer att krävas 

måste ändå ha många egenskaper som hos motsvarande kompilator för att överhuvud taget 

kunna förstå programspråket som det ska analysera, i det här fallet Rapid. 

1.3 Skal 

Eftersom det inte var helt bestämt vilka egenskaper som först och främst var intressanta i 

Rapid-programmen så är det givetvis allra bäst om man utan alltför stora ansträngningar kan 

bygga ut analysen till även andra egenskaper, t. ex död kod. Detta ingår inte i examensarbetet 

och inte heller att göra ett kodskelett, eller skal, där man utan att ens behöva programmera 

särskilt mycket i de viktigaste filerna kan bygga ut analysen. 

1.4 Waitstate - Definering 

Definitionen av viloläge är att programmet inte går till något nytt kommando, antingen gör det 

ingenting eller så ges det en viss tid att vänta att den aktuella operationen ska bli klar. Vissa 

kommandon i Rapid kan också sluta innan den angivna tiden om de hinner bli klara innan. 

Ytterligare en del väntekommandon handlar om kommunikationen med robotsystemet och 

andra handlar om att läsning från en fil ges en viss specificerad tid. 

1.5 Tidsbestämning i programmet 

Flera waitkommandon väntar bara en viss tid på att få utföra sin åtgärd, frågan är hur lång den 

tiden ska få vara i de mest tidskritiska lägena. Det enda rimliga tycker jag är att användaren av 

analysprogrammet själv får specificera det. Hur detta går till finns beskrivet i avsnitt 5.4.2. 

6

1.6 När är waitstate intressant 

Det är inget problem om programmet hamnar i waitstate, bara inte det är en trap, händelse, 

som är orsaken till den. En trap har nämligen triggats igång av en signal (se avsnitt 2.6.3 och 

3.2.2) utanför robotsystemet och när så är fallet vill man att responsen inte ska ta för lång tid. 

Det är orsaken och motiveringen till sökningen efter väntekommandon under den 

omständigheten. Det aktuella kommandot, t. ex WaitTime, ligger då i trapens programflöde 

(se avsnitt 3.2.4). Det kan, men behöver inte vara, inom den subrutin som är själva trapen. Det 

kan också vara i en annan rutin som anropats från trapens subrutin, eller i en lång kedja av 

subrutiner och funktions och procedur anrop där trapen är den ytterst sändande rutinen. 

Analysprogrammet måste alltså kunna avskilja olika programflöden från varandra för det kan 

också vara så att det är main-funktionen i Rapidprogrammet som är roten i programflödet. 

1.7 Oinitierade variabler - Risker 

Om en oinitierad variabel används vid t. ex en tilldelning av en annan variabel, så kan man 

vara tämligen säker på att i det här fallet Rapid-programmeraren haft intentionen att den skulle 

vara initierad. Förmodligen är det ett slarvfel som gör att den inte är det, vid sidan om att det 

är dålig programmering att den inte är det. Något syntaktiskt fel är det dock inte att använda 

oinitierade variabler. Detta fel, där orsaken kanske inte är så enkel att finna, kan också 

fortplanta sig mellan rutiner via parametrar. Den mottagande rutinens parameter används som 

den vore initierad fast den inte är det, liksom i föregående avsnitt så handlar det om att 

undersöka programflöden. 

7

2. Rapid 

2.1 Användningsområde 

Rapid är ABB:s interna språk för programmering av robotar. Det har många likheter med både 

C och Pascal och innehåller kommandon för iteration, selektion och subrutiner. Förutom det 

så har det många kommandon som är specifika för de robotar som ska ta instruktioner från 

detta. Dessa gäller bland annat fart, acceleration, möjlig last och positioner för roboten att 

hålla. Det finns också ett antal direkta Move kommandon, t. ex MoveL där roboten ska röra 

sig längs en rak linje. Det är även möjligt att via programspråket ta hand om händelser och 

utföra kommandon utifrån dessa, i andra programspråk kallas det vanligtvis för ett event, i 

Rapid för trap. 

2.2 Moduler och TASK:s 

"An RAPID application is called a task. A task is composed of set of modules. A module 

contains a set of data and routine declarations". 

[RAPID kernel reference] (s. 1) 

Den första sektionen i en modul täcker versioner och språk och kan se ut så här: 

%%% 

VERSION:1 

LANGUAGE:ENGLISH 

%%% 

[RAPID overview] (s. 88) 

Därefter kommer Module-nyckelordet och sedan datadefinitioner som t. ex enligt följande: 

MODULE PForders 

VAR num newmancmd:=0; 

CONST num NOCMD:=0; 

CONST num MIN90:=1; 

MODULE korresponderar mot ENDMODULE som således ska komma sist i filen. Här liknar 

Rapid Visual Basic en del. 

Sedan kommer rutindeklarationer där återigen de lokala datadeklarationerna ska komma först, 

exempel: 

PROC changeDock(num dockid) 

VAR navPos tmppos; 

Efter det kommer kommandona inuti rutinerna. Programmet startar upp i en rutin som heter 

main(), alltid utan parametrar, det kan även heta haupt() om det är en tysk module-version. 

Endast en main()-rutin får finnas i ett task, fast ett rapid-projekt kan bestå av många filer och 

moduler. Ett task är att likna vid ett körbart program på andra plattformar. 

8

Det går att nå variabler som är deklarerade som fördefinierade datatyper (se avsnitt 2.3.3) över 

alla moduler som ingår i ett task, om dessa är deklarerade i någon. Det går också att anropa 

procedurer och funktioner på samma sätt, om dessa inte har nyckelordet LOCAL framför 

deklarationen, då kan de bara anropas inom modulen. Egendefinierade datatyper (se avsnitt 

2.3.4) har dock bara en räckvidd som sträcker sig över den modul som de är deklarerade inuti. 

2.3 Datatyper i Rapid 

2.3.1 Olika sorters data 

Information kan som i alla programspråk hållas i data, i Rapid finns det tre sorters data, 

konstanter, variabler och persistants. En konstant får sitt värde i samband med att den 

deklareras, en variabels värde kan däremot ändras senare i programmets flöde, en persistant 

sparar sitt värde tills nästa programkörning. Data kan också ha olika räckvidd, som i de flesta 

programspråk gäller det t. ex variabler inuti en subrutin vs globala. Men i Rapid finns det 

ytterligare en nivå, nämligen inuti en modul eller för hela programmet. Default är i modulen, 

men med nyckel ordet GLOBAL kan det gälla för hela programmet. Annars kan man för 

tydlighetens skull också använda nyckelordet LOCAL som kan sättas innan deklarationen. Se 

exempel: 

LOCAL VAR intnum im90; 

Om det skulle finnas en global variabel med samma namn så skulle den i exemplet gälla inom 

aktuell modul, den gömmer den globala motsvarigheten. Observera att i exemplet så är im90 

inte initierad. 

När vi sedan närmar oss olika datatyper kan dessa också delas in i kategorierna atomiska, 

array och recorddatatyper samt aliasdatatyper. Atomiska innehåller bara ett värde, recordar en 

en uppsättning av flera vilka kan vara av olika typ, medan arrayer är en serie av möjliga 

element där alla är av samma typ. Det är fullt möjligt för en array att innehålla en serie av 

arrayer. Alias ikläder sig någon av de förstnämnda utan att direkt vara deklarerad så. Man kan 

deklarera en variabel som alias-datatypen errnum (som är beskriven i 2.2.2) och den kan då 

ges samma värden som datatypen num. 

2.3.2 Hur initieras data 

Variabler och persistants etc, kan initieras direkt vid sin deklaration som i de flesta 

programspråk, Ett exempel: 

PERS num GNTraceLevel:=0; 

Persistant-variabeln heter GNTraceLevel, har datatypen num och har just nu värdet 0. 

Tilldelningtecknet är detsamma på nästan alla andra ställen i Rapidkoden, endast en viss typ 

av parametrar tilldelas på ett annat sätt. Lite senare i rutinen kan man tänka sig programraden: 

GNTraceLevel:=1; 

och GNTraceLevel blir initierad om den inte redan vore det förut. Initiering kan också ske 

som beskrivs i avsnitt 2.4.5, i en rutin som anropas, både som beskrivs där med 

parameteröverföring, eller att det helt enkelt handlar om en global variabel med räckvidd över 

bägge rutinerna, eller rent utav modulerna. Det allra mest extrema fallen är när initiering sker i 

ett annat men synkroniserat task, vid multimove, se avsnitt 2.3.1 om persistants. 

Analysverktyget måste kunna identifiera initieringar utanför den aktuella subrutinen, och 

dessutom om det sker i en annan modul, samt att det med antagandet att den digitala rutinen 

som eventuellt anropas initierar den sändande oinitierade parametern, initierar denna. 

9

2.3.3 Fördefinierade datatyper 

De datatyper som redan är definierade från början i rapid är bool, num och string när det gäller 

de atomiska. Det finns tre recorddatatyper som är fördefinierade också, pos, orient och pose, 

de uttrycker alla olika sorters koordinater, samt två aliasdatatyper, intnum och errnum. 

Intmum används för att hålla reda på händelser, errnum för fel. 

2.3.4 Egen definierade datatyper 

Det går även att definiera egna datatyper i Rapid. Dessa är vanligen recorddatatyper. Här är 

navPos exempel på en sådan från ett riktigt Rapidprogram. 

RECORD navPos 

num seqwindow; 

num x; 

num y; 

num z; 

num angle; 

ENDRECORD 

2.3.5 Installerade datatyper 

De installerade datatayperna har tillkommit bland annat för att göra programmen mer lättlästa. 

Om man har installerat t. ex de ganska komplexa recordarna robtarget eller speeddata, så kan 

man deklarera t. ex variabler utifrån dessa vart som helst. Till skillnad från de egendefinierade 

så finns dom inte deklarerade i Rapids källkodsfiler. De tillhör å andra sidan inte heller Rapids 

kärna. Det kan finnas många installerade datatyper i den aktuella Rapid miljön. Så här 

sammanfattas installerade datatyper i relation till de fördefinierade och egendefinierade i 

ABB: Rapid Kernel Reference dokument: 

“Built-in types are a part of the RAPID language while the set of installed or user-defined 

types may differ from site to site. From the users point of view there is no difference between 

built-in, installed and user-defined types”. 


2.4 Kommandon i Rapid 

2.4.1 Selektion 

If är i Rapid liksom flera uttryck mycket likt sin motsvarighet i Pascal, se t.ex följande 

exempel: 

If Counter > 100 then 

Counter := 100; 

ELSEIF Counter < 0 then 

Counter := 0; 

ELSE 

Counter := Counter + 1; 

10

ENDIF 


Dessutom finns i Rapid kommandot CompactIf där man bara kan ha ett villkor samt att bara 

en truedel finns tillgänglig. Ett annat Pascal-liknande kommando är Test, se följande 

exempel: 

TEST choice 

CASE 1,2,3: 

picknumber := choice; 

CASE 4: 

stand_by; 

DEFAULT: 

write consol, "Illegal choice"; 

ENDTEST 


2.4.2 Iteration 

Dels finns For som i det här exemplet: 

FOR i FROM 10 TO 1 STEP -1 DO 

a{i}:=b{i}: 

ENDFOR 


och dels While som i följande: 

WHILE a

ingen parametertyp anges) och REF. Parametertypen INOUT skickar, som namnet antyder, 

tillbaka det uppdaterade värdet till den skickande rutinen, i motsats till IN som bara tar emot. 

REF är som namnet antyder en referens till den skickande rutinens parameter. De rutiner som 

man skapar i Rapid kan dock inte vara av typen REF, det gäller bara fördefinierade, eller 

digitala rutiner, se avsnitt 2.4.5. Parametertypen INOUT gör att parametern blir VAR eller 

PERS beroende på vilket det motsvarande argumentet i den sändande rutinen har. 

Vissa parametrar i den mottagande rutinen uppdaterar även den sändande rutinens parametrar, 

eller argument. Det är beroende på hur de är deklarerade. IN i den mottagande rutinen 

uppdaterar inte den sändande rutinens parameter, eller argument, men INOUT, VAR, PERS 

och REF gör det. 

Alla parametertyper kan från den sändande rutinen inte nå, eller accessa, alla parametertyper i 

den mottagande rutinen, och vissa överföringar mellan parametertyper är inte tillåtna. Se 

tabell 2.1. 

Tabell 2.1 

12


Den sändande rutinens parametrar ligger i höjdled, den mottagande i sidled. Argumenten är 

också parametrar i den sändande rutinen. Observera att det kan göra skillnad om den sändande 

parametern i sin tur är en parameter, och inte en vanlig rutin variabel. Om den mottagande 

parametern är en PERS så ska den sändande också vara det i alla fall. Alla datatyper går att 

skicka som parametrar, även arrayer. Här är ett exempel på hur en procedur kan deklareras 

med två parametrar varav den ena är en array: 

PROC arrmul(VAR num array{*},num factor) 

FOR index FROM 1 TO Dim(array, 1) DO 

ENDFOR 

ENDPROC 


array{index}:=array{index}*factor; 

Anropas denna procedur med t. ex två VAR deklarerade parametrar kommer den förstnämnda, 

arrayen, att uppdateras i proceduren. Den mottagande arrayens storlek blir densamma som den 

sändande efter * direktivet i denna. Med kommandot Dim fås storleken i form av ett heltal 

sedan. När programmet når ENDPROC, ENDFUNC, respektive ENDTRAP, som ska avsluta 

rutinkroppen, avlutas rutinen, samt ifall det stöter på kommandot RETURN. Anrop av 

funktioner och procedurer ser olika ut beträffande parametrar. Funktioner ska ha ”(” komma- 

separerad parameterlista ”)” (undantaget är digitala funktioner, se 2.4.5, med tom 

parameterlista). Ett exempel: 

CRC:=countCRC(bindata,len+2); 

I procedurer så kommer parametrarna, eller argumenten, på rad direkt efter procedurnamnet, 

t.ex: 

WriteBin maxondev,bindata,1; 

2.4.5 Digitala rutiner 

Dessa kan lika gärna kallas för fördefinierade funktioner i Rapid. En sådan som vi sett i 

stycket ovan är Dim som ger antalet existerande element i en array. Ett exempel på en digital 

procedur som nämnts i avsnitt 2.1 är MoveL som förflyttar aktuellt verktyg längs med en linje 

till en punkt i ett tredimensionellt rum. T. ex MoveL p1, v500, z10, tool1; De tre första 

parametrarna utgör en koordinat, den fjärde är aktuellt verktyg. 

2.4.6 Egendefinierade rutiner 

Dessa anropas på precis samma sätt som de digitala. I en modul (se sida 9) ska rutiner 

deklareras i den sista sektionen. Ett exempel på en egendefinierad rutin finns i två stycken 

ovan. På sida 8 finns ett exempel på en egendefinierad Trap. 

13

2.5 Goto 

Precis som subrutiner utgör ett hopp i programmet rent syntaktiskt, så gör även GOTO det. 

GOTO med ett strängargument gör att programmet hoppar till programraden efter labeln som 

är själva argumentet. Ett exempel: 

next: 

i:=i+1; 

------ 

GOTO next; 


Gör att programmet hoppar till raden under next. Det är bara att skriva next, såtillvida det inte 

finns någon rutin med åtkomst som heter så redan, och givetvis får det inte finnas någon 

digital rutin som heter så för då körs den istället. Det är inte tillåtet i Rapid att via GOTO 

utifrån hoppa in i strukturerade block som loopar och villkorssatser. 

2.6 Trapar 

2.6.1 Inledning 

En trap kopplas kopplas till händelse och om den inträffar så går programmet till den trapens 

kod. Efter det fortsätter programmet som vanligt på det ställe som programpekaren var på. En 

trap kan dock inte utlösas när en annan trap redan kör. Hur detta förhindras och mer går att 

läsa i avsnitt 2.6.3. 

2.6.2 Deklaration 

Att deklarera en trap går till på samma sätt som en procedur eller funktion, fast den kan inte 

ha några parametrar eller vara en datatyp. Annars kan den hålla egna datatyper och 

kommandon precis som all annan kod. En trap slutar köras då den når kommandot ENDTRAP 

(på samma nivå som TRAP) eller när den når kommandot RETURN. Då återgår programmet 

till det ställe det var innan trapen exekverades. Ett exempel: 

TRAP regulate_trap 

ENDTRAP; 

VAR num TRAPalpha; 

----------------- 

----------------- 

RETURN; 

----------------- 

----------------- 

2.6.3 Deklaration Associera med händelse 

14

Med kommandot CONNECT kopplas en deklarerad trap ihop med en händelse. En händelse 

är någon slags input som kommer utanför Rapidsystemet till roboten. Efter CONNECT ska en 

identifierare som är av datatypen num eller en alias för num följa. 

VAR intnum orderint; 

CONNECT orderint WITH regulate_trap; 

Lika viktigt är det att definiera interruptet och göra det aktivt för systemet. Kommandot 

ISignalDI gör bådadera. Ett exempel får belysa saken: 

ISignalDI sig1, high, orderint; 

Kommandot ISignalDI kopplar här samman den fördefinierade händelsen sig1 med orderint 

(se exemplet ovan) medan high anger hur stakt utifrån kommande input är. 

Med kommandot ISleep kan man deaktivera interruptet, med IDelete kan man ta bort det och 

med IDisable kan man göra så att de får stå tillbaka för annan kodexekvering. Detta sker t. ex 

automatiskt för alla andra trapars interupt, när en trap körs. 

2.7 Filstruktur i Rapid 

2.7.1 Sysmod 

Ett rapidprojekt är rent fysiskt organiserat så att det innehåller två underbibliotek, ett som 

heter SYSMOD. Där lägger man som jag förstår oftast förprogrammerade filer och moduler 

som ligger närmast robotsystemet och dess instruktioner, händelser, konstanter mm. Filerna 

här har ändelsen .SYS 

2.7.2 Progmod 

Här ligger den filerna som är specifika för själva uppgiften, programmets task kan man 

uttrycka det. Här finns också mainrutinen som programmet startar upp ifrån. I övrigt finns det 

inga skillnader hur man ställer upp filerna gentemot i SYSMOD-biblioteket. Filerna här har 

ändelsen .MOD. 

2.7.3 Ihoplänkning av ett Rapidprojekt 

Tasken binds ihop av filerna/modulerna i PROGMOD och SYSMOD-biblioteken. Ett 

alternativ är att man har en enda programfil som har tillägget .PRG. 

15

3. Analys 

3.1 Programflöden 

3.1.1 Programflöden generellt 

Ett programflöde, eller en programflödesväg kan starta i programmets huvuddel, i exempelvis 

C så sker det i main-rutinen. Det kan sedan välja en av true eller false-delen i en if-sats, sedan 

gå till ett funktionsanrop och hoppa i programmet rent syntaktiskt till den funktionen, loopa 

ett antal varv i en while-sats osv. Antalet programflödesvägar i ett program kan bli väldigt 

många, ja till och med oändligt om man inte sätter stopp för t. ex alltför många rekursiva 

anrop i en rutin. 

3.1.2 Programflöden i optimerande kompilatorer 

Optimerande kompilatorer tar en del hjälp av programflödesanalys för att ta bort en del 

onödiga rader, t. ex så kan det andra uttrycket i en sekvens av två kanske skrivas på ett enklare 

sätt med hjälp av resultatet från det första, ett exempel: 

a := b + c 

b := a - d 

c := b + c 

d := a – d 

[Aho, Sethi , Ullman, 88] (s. 600) 

Man kan lika gärna skriva d := b i sista raden. Det är uppenbart att alla dessa uttryck ligger i 

samma programflödesväg vilket är upp till kompilatorn att lista ut. Optimerande kompilatorer 

tar även bort död kod, t. ex så stryks rader där variabler tilldelas om de inte sedan används. 

Likaså stryks vägar om villkoret för dessa aldrig kan uppnås. För att spara minne så kan 

temporära variabler strykas och ersättas med en annan befintlig, om dess värde alltid är 

detsamma som dennas. Ytterligare en sak som optimerande kompilatorer kan göra är att byta 

ut ordningen på vissa uttryck, om det är smart, förutsatt att dessa inte påverkar varandra på 

något sätt givetvis. Dessutom sker alltid detta inom samma block. 

Optimerande kompilatorer delar in koden i block. Det kan bestå av en eller flera satser. Den 

första programraden inleder alltid ett block, och kod som kan nås via hopp (också hopp via 

rutinanrop) inleder också ett nytt block. Att optimera koden inom ett block är inte så svårt, 

men framför allt för att klara det mellan olika block så använder optimerande kompilatorer 

också något som heter Programflödesekvationer. Detta för att på ett systematiskt sätt ta reda 

på vilken information som finns, och inte är död genom att den skrivits över, inför och efter 

varje uttryck. Den enklaste Programflödesekvationen ser ut enligt följande: 

out[S] = gen[S] U (in[S] - kill[S]) 

[Aho, Sethi , Ullman, 88] (s. 608) 

16

Den information, om t. ex vilka variablers värden som är intressanta, består av det som satsen 

S genererat plus informationen innan S minus det som S raderat ut, t. ex genom att ta 

minnesutrymmet för en variabel i anspråk. Tre andra grundläggande Programflödesekvationer 

behandlar: en sats som kan brytas ner till två satser (S -> S1 ; S2), val (selektion) och loopar. 

Ett sätt att lösa ekvationssystemet av Programflödesekvationer för ett helt program, är att 

programmet från början betraktas som en enda sats S, den har inget input överhuvudtaget. 

Därefter bryts S ned till delar med Programflödesekvationer och då kan man få statusen, t. ex 

beträffande variablers värden, i sitt program vid varje enskild sats. 

Lika vanliga är ekvationer som analyserar koden baklänges. Det vill säga man räknar ut vilken 

information som finns när man går in i en sats utifrån vilken som förelåg när man kom ut ur 

det. Återigen är det dock enklast för optimerande kompilatorer att jobba med block istället för 

satser. Observera att ett block som kommer efter rent fysiskt i programmet mycket väl kan 

generera eller döda information för ett block som kommer innan, bara det finns en väg i 

programmet dit. 

En annan metodik för att upptäcka bland annat just oinitierade variabler, generellt, är 

”reaching definitions”. Där utgår man från själva definitionen d, av t. ex en variabel i en 

tilldelningssats, och tittar på hur länge den sträcker sig genom de nästföljande blocken och 

satserna i programmen. Om tidigare nämnda d gäller senare i programpunkten p, där kanske 

just denna variabel används, är det är acceptabelt. Definitionen d kan också skrivas över av 

andra definitioner innan p, och då gäller istället dessa. 

För att veta om en viss information finns om t. ex en variabel finns också begreppen 

otvetydiga definitioner av dess värde, och tvetydiga [Aho, Sethi , Ullman, 88] (s. 610). 

En direkt tilldelning av en variabel är otvetydig. En tvetydig kan vara en variabel som skickas 

in i en funktion som parameter, och det är inte bara värdet som behandlas utav den ("call by 

value") utan även referensen, parametern, uppdateras. Det kallas för "call by reference", se 

avsnitt 1.7 Optimerande kompilatorer måste betrakta även tvetydiga definitioner som gen[S], 

men bara otvetydiga kan åstakomma kill[S]. Det som kommer ut ur en sats är givetvis det som 

kommer in i nästa. Det går därför att beräkna informationen som finns vid varje ställe i varje 

programflödesväg. Information som visar sig värdelös på några ställen kan leda till 

optimeringar i koden. 

3.2 Programflöden i Rapid 

3.2.1 Start av ett programflöde 

Ett programflöde, eller en programflödesväg, startar i Rapid i satsen main (se avsnitt 2.2) 

såtillvida det inte är en händelse som utlöst den via en trap (se avsnitt 2.6). Ett exempel från 

ett riktigt Rapidprogram: 

PROC main() 

nextorder; 

ENDPROC 

ENDMODULE 

Observera att main här är det sista som finns i modulen rent fysiskt. En mainrutin, varken mer 

eller mindre, ska finnas i ett program men det behöver inte ligga i någon speciell modul. En 

trap kan som sagt starta ett programflöde, bara den är connectad innan, det kan t. ex ske i main 

eller i main:s programflöde eller i en annan trap eller traps programflöde. Här ett exempel på 

hur en trap startar ett programflöde: 

TRAP minus90_trap 

IF DIDockOK=0 THEN 

17

newmancmd:=MIN90; 

ENDIF 

ENDTRAP 

Man skulle kunna säga att allt som sker i Rapid-programmet är en enda programflödesväg i 

grunden, där connect och körning av trapar bara är delvägar i denna. Fast det är enklare om 

körning av en trap får betraktas som en egen. I analysen av programflödesvägen i 

analysprogrammet (se avsnitt 5) sker så och man kan ställa in om man bara vill titta på 

connectade trapars möjliga vägar, eller allas. 

3.2.2 En programflödesväg 

I exemplet i avsnittet ovan börjar programflödesvägen med main, sedan proceduren nextorder, 

program flödesvägen går ovillkorligt dit i det här fallet, i nextorder sker i början följande i 

samma Rapidprogram: 

MODULE PForderhandl(SYSMODULE) 

PROC nextorder() 

WaitDO DOtaskPFReady,1; 

Den digitala rutinen (se avsnitt 2.4.5) WaitDO körs ovillkorligt, vad som sker i den kan inte vi 

eller analysprogrammet veta exakt. Fast före WaitDO i programflödesvägen ligger faktiskt 

parametern DOtaskPFReady som i sin tur är en digital rutin. Det är den digitala funktionens 

returvärde som skickas som parameter. Observera att nextorder ligger i en annan modul och 

en systemmodul (se avsnitt 2.2). När WaitDO körts fortsätter programflödet till efterföljande 

kommandon. Vid selektion (se avsnitt 2.4.1) delar vägen på sig i flera som alla måste 

analyseras. 

3.2.3 Nästa programflödesväg 

Detta berördes något i avsnittet ovan. Ett lite större exempel får belysa hur fler 

programflödesvägar kan gestalta sig: 

IF relevant(irRightR)>relevant(irRightL) THEN 

use_irright:=1; 

MPMoveLinDist 0.3,0.02,90; 

WaitUntil Abs(relevant(irRightL)- relevant(irRightR)) 

MPBreak; 

ENDIF 

Efter truedelen i det yttre villkoret måste även false delen analyseras. Dessa råkar i det här 

fallet av en tillfällighet vara ganska lika varandra, men så behöver det inte vara. Även inom 

dessa båda programflödesvägar skulle nya vägar kunna utkristallisera sig om villkoret IF 

timeout THEN även hade en false del. Observera att true delen inte på något sätt får ändra 

villkoren och den tillgängliga informationen beträffande t. ex globala variabler för false delen 

(se avsnitt 4.5.3). 

3.2.4 Trapars programflöde 

Hur trapars programflöde startar har berörts i 3.2.1. Observera att om en trap beställs så 

bryter den som default pågående programflöde, som startats av main, och går in emellan. En 

trap kan dock inte starta om en annan traps programflöde redan pågår. 

3.3 Waitstate 

3.3.1 Intressanta programflöden beträffande Waitstate 

Programmet kan hamna i viloläge under körning av vissa kommandon (se avsnitt 3.3.2). Det 

är tillåtet i main:s programflödesväg, men inte i trapars. ABB:s rapidkompilator upptäcker 

inte det utan att upptäcka det är en av själva anledningarna till det här examensarbetet. Som 

nämnts flera gånger tidigare är det inte bara koden inom själva trapen rent fysiskt som måste 

checkas utan i alla trapars möjliga programflödesvägar. Analysen av Rapidkoden för att hitta 

väntekommandon sker enligt samma princip som för att hitta oinitierade variabler, vilket 

beskrivis i avsnitt 3.4. Men det är betydligt enklare att hitta ett väntekommando än att avgöra 

om en variabel ska betraktas som initierad eller ej. Det räcker alltid med att väntekommandot 

ligger i någon del av programflödesvägen, vid t. ex en if-sats. Dessutom består processen när 

det gäller väntekommandon bara av en del, variabler initieras ofta på ett ställe och används på 

ett annat. 

3.3.2 Kommandon som genererar Waitstate 

Definitionen av viloläge är att programmet inte går till något nytt kommando, antingen gör det 

ingenting som vid kommandot Waittime, eller så ges det tid att vänta att den aktuella 

operationen ska bli klar. Waittime kan sluta innan given tid i tidsparametern också, om en 

robot som rör på sig slutar med det. WaitUntil med en boolsk parameter bakom gör att 

programmet väntar tills att den är satt till sant. Ett exempel: 

PERS bool startsync:=FALSE; 

PROC main() 

WaitUntil startsync; 

-------------------- 

-------------------- 

[RAPID overview] (s. 136) 

Exemplet är hämtat ifrån Multitasking mellan två robotar. Just persistants (se avsnitt 2.3.1) är 

åtkomliga mellan olika processer, tasks i Rapid, så startsync uppdateras i det här fallet från en 

annan process. De två övriga kommandona som börjar på "wait" är WaitDO och WaitDI. 

19

WaitDO är för att försäkra sig om att en signal från Rapid gått ut till Robotsystemet, och 

WaitDI för att vänta på att en signal in ska komma. Dessutom kan programmet ges tid att 

vänta när vissa datatyper ska läsas in från t.ex fil, exempel på sådana kommandon är ReadStr, 

ReadNum, ReadAnyBin och ReadBin. 

3.4 Programflödesekvationer avseende initiering av variabler 

Detta avsnitt behandlar förfarandet när variabler registreras som initierade. För att de ska bli 

det måste de överfört till programflödesekvationer bli det via en sats S, och det får inte finnas 

någon möjlighet att informationen om att de är det går förlorad, t. ex genom selektionssatser 

eller loopar. Detta innan variabeln används. Initiering sker ytterst i en tilldelningssats, därför 

är gen (se avsnitt 3.1.2) utelämnat i de andra satsalternativen i tabell 3.1. Fast man kan absolut 

tänka sig gen (generate) i en godtycklig sats S. Kill är däremot helt utelämnat, en initiering 

kan nämligen inte tas bort. Gen [S] är vänsterledet vid en korrekt tilldelning. Observera att i 

tabellen är flera satstyper, för loopar och vilkor, uppdelade i två delar. Vanligtvis annars 

repressenteras t. ex en If-sats enligt S = if b then S1 else S2. Här är är huvudet i t. ex if-satsen, 

vilket är själva vilkoret, skiljt från de i analysen efterkommande satslistorna, dvs de olika 

vägarna som programmet kan ta. I praktiken borde de sistnämnda vara de klart viktigaste för 

den här analysen, även om det t. ex är viktigt att loopvariabeln i en while-sats får räknas som 

initierad när den eventuellt senare använs. Analysprogrammet protesterar dock givetvis på 

samma sätt om oinitierade variabler används i huvudet i en loop eller selektionssats, som om 

det sker i någon av dess satslistor. 

Tilldelning out [S] = gen [S] U in[S] 

Sekvensering av två satser, 

Header vid selektion, 

Header vid loopar 

Satsdel vid selektion där någon 

del garanterat körs 

Satsdel vid selektion där det inte 

är säkert att någon del körs 

in [S1] = in [S] 

in [S2] = out [S1] 

out [S] = out [S2] 

in [S1] = in [S] 

in [S2] = in [S] 

out [S] = out [S1] snitt out [S2] 

in [S1] = in [S] 

in [S2] = in [S] 

out [S] = in [S] 

Satsdel för loopar in [S1] = in [S] 

out [S] = in [S] eller 

out [S] = in [S1] 

Tabell 3.1 

Jag har valt en ansats i det här examensarbetet med att en programflödesväg kan starta i 

main() eller i en trap. Hela detta flöde av satser därifrån kan beskrivas som en sats S. För att 

bryta ner flödet i mindre satser kan en notation med programflödesekvationer användas. När 

en sats bryts ner till två (S -> S1 ; S2), och varken loopar eller selektion är inblandade 

beräknas informationen om huruvida variabler är initierade enligt: 

in [S1] = in [S] 

in [S2] = out [S1] 

20

out [S] = out [S2] 

S i S -> S1 ; S2 kan i första steget vara hela programmet, S1 första satsen innan semikolon 

och S2 resten av programmet. I nästa steg är S det som i första steget är S2 osv. 

Vid selektion, t. ex genom en If-sats, ser ekvationerna ut på samma sätt som tabell 3.1 när det 

gäller headern (villkorsdelen för t. ex If). För satsdelarna handlar det om vägval. S1 är en 

väg, t. ex en if-del, S2 en annan, t. ex en else-del. Egentligen kunde ekvationerna ha ställts 

upp med ett godyckligt antal vägar. Ekvationerna se ut på två olika sätt, beroende på om 

någon satsdel garanterat körs eller inte. Om någon del körs, det gäller If-satser med Else-del 

och Test-satser med en Defaultdel, ser ekvationssystemet som i andra alternativet i tabell 3.1: 

in [S1] = in [S] 

in [S2] = in [S] 

out [S] = out [S1] snitt out [S2] 

Observera att den nedersta ekvationen inte är densamma som nämns ofta i kompilatorteori 

som istället ger: 

out [S] = out [S1] union out [S2] [Aho, Sethi , Ullman, 88] (s. 612) 

som grundläggande. I den här analysen måste en variabel (som inte är initierad innan 

selektionen) initieras i alla vägar. Annars kommer detta att resultera i en varning att den inte 

kan garanteras vara initierad vid slutet, out [S], om den senare används. Tabell 3.1 visar hur 

detta ser ut vid två vägar, t. ex vid IF där det finns en if och en else-del, men det gäller 

generellt vid godtyckligt antal vägar. 

Vid selektion där det inte är säkert att Rapidprogrammet tar någon väg genom satsdelarna 

gäller programflödesekvationer enligt: 

in [S1] = in [S] 

in [S2] = in [S] 

out [S] = in [S] 

Man kan inte vara säker på att initiering sker, även om detta sker för t. ex en speciell variabel i 

alla befintliga vägar vid selektionen, eftersom möjligheten finns att ingen väg tas. Detta gäller 

för Rapid kommandot CompactIf samt If-satser utan en Else-del och Test-satser utan en 

Defaultdel. 

Vid loopar, som i Rapid kan vara For och While loopar, gäller första alternativet i tabell 3.1 

för headern, informationen som denna genererar förs alltid vidare. Antalet gånger som 

loopens header utvärderas är en. Vilka slutvärden som variabler tenderar att få i loopens 

header är inte intressanta, bara om de är/blir initierade. Därför antas resultatet bli detsamma 

för koden i headern oavsett hur många gånger som den verkligen utvärderas 

För satsdelen för loopar gäller sista alternativet i tabell 3.1. Den grammatiska är 

beskrivningen S -> S1, där S är en generell sats, medan S1 säger mer specifikt att det är en 

loops satsdel. 

in [S1] = in [S] 

out [S] = in [S] eller out [S] = in [S1] 

21

Loopen har en entry punkt till sig själv, men det tar inte den här analysen hänsyn till, därför 

den första ekvationen. I den andra ekvationen kan man välja om man vill förhålla sig till S, 

som säger att det är en sats, och S1 som säger att det är en loop. Det som S1 (och S) genererar 

i form av eventuella initieringar tar den här analysen inte hänsyn till efteråt, eftersom det inte 

är helt säkert att detta kommer att ske (0 varv). En loops satsdel påverkar här alltså inte alls 

informationen för vad som kommer ut ur den. Detta för att informationen om huruvida 

variabler med mera blivit initierade ska vara säker. 

Observera dock att när S1 bryts ned inuti loopen, i egna satser, så kan det ske enligt de andra 

ekvationssystemen, om initieringar sker då så är dom intressanta just inuti loopens satsdel. 

Programflödet kan göra ”hopp” i Rapidkoden med funktions och proceduranrop (se t. ex 

4.5.4), samt via GOTO. Självklart ska informationen innan hoppet tas med till 

hoppdestinationen samt tillbaka när hoppet är gjort. I övrigt så påverkas och försvåras inte 

analysen just av att man flyttar programpekaren. Det är inte tillåtet i Rapid att via GOTO 

hoppa in i loopar och satslistor, se avsnitt 2.5. Då hade analysen också blivit mycket svårare. 

3.5 Oinitierade variabler, parametrar och recordar 

3.5.1 Hur upptäcka att variabler ej blivit initierade 

Hur variabler initieras finns beskrivet i avsnitt 2.3.2. När en variabel sedan används, t. ex på 

höger sida i en tilldelningssats eller vid utskrift eller när den skickas som en parameter till en 

annan rutin, måste man veta att den verkligen är initierad, det är den andra anledningen till 

just det här examensarbetet. Jag har valt att spara information om variablers tillstånd i något 

som jag kallar för symboltabeller, där initiering med mera, finns sparat. Har variabeln inte 

hunnit tilldelas under programflödesvägens gång när den används, så kommer detta att 

upptäckas tack vare symboltabellernas information. 

3.5.2 Symboltabeller 

Symboltabeller används i alla kompilatorer och förmodligen alla analysverktyg som detta. De 

innefattar också här, såväl rutiner som variabler etc. I kompilatorer är en av 

huvudanledningarna typkontroll, här är det att hitta oinitierade variabler. I många kompilatorer 

skapar man en ny symboltabell för varje rutin, samt en global. Här skapas inte nya 

symboltabeller på det kriteriet, utan istället kan den dela sig i flera om det dyker upp separata 

programflödesvägar. Läs mer om det som jag kallar symboltabeller, och dess medlemmar och 

plats i programmet i avsnitt 5.5.4. 

3.5.3 Globala variabler 

Med globala variabler menas i programmering generellt variabler som har en räckvidd som 

sträcker sig över hela programmet. De deklareras inte i någon rutin, inte heller i main, utan 

utanför. Under ett programflödes gång så finns det alltid bara en instans av variabeln att hålla 

reda på, även om man kan behöva så att säga återställa informationen om denna när en ny 

programflödesväg ska analyseras (se avsnitt 5.5.8). I Rapid så kan även variabler gälla inom 

modulen och inom hela programmet. 

3.5.4 Lokala variabler 

Lokala variabler har bara en räckvidd inom den egna subrutinen. Om programflödet sträcker 

sig utanför den, men man fortfarande är intresserad av att hålla reda på informationen om 

22

variabeln, så får man skicka den via en parameter. Kompilatorer och stackkodsprogram som 

använder symboltabeller skapar i regel en ny symboltabell (se avsnitt 5.5.5) dynamiskt, med 

de lokala variablerna. Observera att det vid t. ex rekursiva anrop av en rutin mycket väl kan 

finnas flera instanser av en lokal variabel på stacken samtidigt. Dessa har då ingenting med 

varandra att göra mer än att de heter likadant och finns i en rutin som också gör det. Om det i 

Rapid finns en variabel som anropas inom subrutinen, och det finns en lokal, lokal för 

modulen och global för hela programmet, som alla heter likadant, så är det den lokala 

subrutinens som nås i första hand. 

3.5.5 Parameteröverföring 

Variabler med alla typer av räckvidd kan skickas in i en rutin, procedur eller funktion, som 

parameter. Beroende på hur den är deklarerad så kan den antingen bara initiera värdet på den 

mottagande rutinens variabel så kallat "Call by value" eller så kan den uppdatera även värdet 

på den sändande rutinens variabel "Call by reference". Man kan till och med skicka in 

oinitierade variabler i en subrutin enbart för att de ska bli tilldelade och initierade. 

Analysprogrammet måste under alla omständigheter klara av att hantera detta sätt för variabler 

och parametrar att bli tilldelade och initierade. Dessutom måste det finnas en metod för att 

hantera variabler som skickas in som parametrar till digitala rutiner, där källkoden inte synlig. 

3.5.6 Recorddatatyper 

3.5.6.1 Vilka medlemmar finns i recorden 

Här är ett exempel på en recorddeklaration från ett riktigt Rapidprogram: 

RECORD navPos 

num seqwindow; 

num x; 

num y; 

num z; 

num angle; 

ENDRECORD 

Inga konstigheter, det finns t. ex recordar som i sin tur innehåller recordar, installerade 

datatyper mm. Så här deklareras en instans av navPos på ett ställe som lokal variabel: 

VAR navPos tmppos; 

Och så här initieras tmppos och används medlemmar, som argument i en procedur, i samma 

rutin: 

tmppos:=globNavPos; 

MPSetPos tmppos.x,tmppos.y,tmppos.angle; 

En symboltabell måste, oavsett om den är lokal eller global, hålla reda på vad som händer med 

varje recordmedlem, precis som om den vore en atomisk variabel (se avsnitt 5.5.7). Även 

enklare kompilatorer måste hålla reda på vilka medlemmar som finns så att punktoperatorn 

alltid används på rätt sätt. 

3.5.6.2 Recordmedlemmars initiering 

En initiering av en recordmedlem skulle kunna se ut enligt följande: 

tmppos.z = z; 

eller: 

tmppos.z = globNavPos.z; 

Det måste märkas i symboltabellen att tmppos.z har blivit initierad efter detta, förutsatt att z 

och globNavPos.z är initerad givetvis. Annars måste analysprogrammet varna för att 

oinitierade variabler används. 

23

3.5.6.3 En hel records initiering 

Ett exempel på det har vi redan sett, nämligen: 

tmppos:=globNavPos; 

Nu bör symboltabellen indikera på att tmppos är helt initerad, förutsatt att globNavPos var det 

givetvis. Ett annat sätt för tmppos att bli det är att alla dess medlemmar blir initierade var för 

sig. Här är också ett exempel på deklaration samt initiering av en välbekant record från samma 

Rapidprogram som tidigare: 

PERS navPos globNavPos:=[0,0,0,0,0]; 

3.5.6.4 Parameteröverföring av recordar 

Det är ingen skillnad på att skicka recordar eller arrayer av t. ex heltal (se avsnitt 2.4.4) som 

parametrar gentemot atomiska variabler. Samma regler gäller för huruvida "Call by value" 

eller "Call by reference" gäller. Om en funktion är deklarerad för att ha t. ex navPos i sin 

parameterlista, så är det just en recordinstans av navPos som ska skickas och tas emot i den 

sändande respektive mottagande funktionen. Analysprogrammet och dess symboltabeller 

måste kunna hantera kombinationen av parameteröverföring samt recordmedlemmars och hela 

recordars initieringsprocess. 

24

4. Metod 

4.1 Programflödesanalys av Rapidprogram och huvudbegrepp 

För att kunna analysera programflöden i Rapid, och lösa uppgifterna med att hitta kommandon 

som eventuellt styr in Rapidprogrammen i vänteläge i en trap:s programflöde, samt förhindra 

att oinitierade variabler används, krävs ett antal steg och hjälpmedel på vägen. Dessa är 

generella för all kompilatorteori och programanalys, även om de här är tvungna att anpassas 

efter just det här programspråket, Rapid, och hur det är uppbyggt. En kompilator utför först en 

lexikal analys för den källkod som den får givet och som den ska transformera till ett 

förmodligen mer maskinnära språk. Där sker kontroll att programmet är uppbyggt av rätt 

beståndsdelar, det kan vara siffror, identifierare och nyckelord, ofta kallas dessa gemensamt 

för Tokens. Därefter kommer den syntaktiska analysen, alla Tokens kan nämligen inte 

kombineras hur som helst, utan enligt givna mönster. Efter det kommer den semantiska 

analysen, där analyseras vad programmet egentligen gör och allt är inte tillåtet här heller. Alla 

datatyper kan t. ex inte tilldelas varandras värden. Det kallas typkontroll och ligger alltså i den 

semantiska analysen. 

4.2 Lexikal analys 

Den lexikala analysen för analysprogrammet skiljer sig inte från vad som förväntas av en 

kompilator. Självklart måste man skriva kommandona och de olika identifierarna på ett 

syntaktiskt korrekt sätt. Rapid består liksom alla programspråk av ett antal Tokens, eller idem. 

Dessa är bland annat rena nyckelord som t. ex while, num, true osv, men kan också vara ident 

(identifierare) De olika idem:en passar ihop enligt ett visst mönster, ett exempel är 

kommentarsatser i Rapid vilket är ett utropstecken, text och radbrytningstecken. Det säger sig 

självt att t. ex en reglerna för t. ex en for-loop är mer komplexa, men principen är densamma. 

4.3 AST och noder – en generell beskrivning 

Under en lexikal analys så bygger kompilatorer vanligtvis samtidigt upp ett abstrakt 

syntaxträd, AST. Överst i det ligger vanligtvis själva programmet, eller Programnoden. Under 

programnoden kommer i ett procedurorienterat programspråk, utan klasser mm, noder för 

rutiner, t. ex Procedurer och Funktioner. Dessa har i sin tur undernoder för varje kommando 

och sedan kanske även för delar av dessa, t. ex uttryck. Variabler mm sparas också i det 

abstrakta syntaxträdet både i den översta Programnoden, om de är globala, och i rutinernas 

noder, om de är lokala. Det är nödvändigt med ett AST om man ska gå vidare med en 

semantisk analys av ett program, oavsett programspråk. 

4.4 AST och noder för Rapid analysprogrammet 

Noderna i analysprogrammets AST är ganska lika en vanlig kompilator, men något enklare. 

Uttryck (exempelvis 1+1) är inte en egen nod här, utan allt innehåll i t. ex en assign sats (t. ex 

a := 1 + 1) bearbetas direkt i Assignnoden, såtillvida att det inte finns undernoder i uttrycket. 

Det kan t. ex vara a := 1 + calculatesomething(1) , alltså ett funktionsanrop. 

25

Tabell 4.1 

TopNode 

Moduler 

Moduler (vektor) 

Attribut (vektor) 

Typer (vektor) 

Variabler (vektor) 

Variabelnamn 

RoutineDefNode (vektor) 

RoutineDefNode 

Namn 

Lokal (boolsk variabel, om synlig utanför modulen) 

Variabler (vektor) 

Variabelnamn 

Satser (vektor) 

Noder 

Error - Satsdel (vektor) 

Noder 

Parameterlista (vektor) 

Parametrar 

Assign 

CompactIf 

If 

Vänsterled (targetImage) 

Högerled (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

Villkor (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

Sats (Vektor) 

Nod 


Noder 

Literaler 

Variabler 

Parametrar 

Satsdel (vektor) 

Noder 

ElseIfNoder (Vektor) 

ElseIfNod 

Else - Satsdel (vektor) 

Noder 

26

ElseIfNod 

Test 

CaseNod 

For 

While 


Noder 

Literaler 

Variabler 

Parametrar 


Noder 

Test (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

Casedelar (vektor) 

CaseNod 

Default(vektor) 

Noder 


Noder 

Literaler 

Variabler 

Parametrar 


Noder 

Loopvariabel 

Variabel 

Parameter 

Fromvillkor (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

Tovillkor (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

Stegdel (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 


Noder 


Noder 

Literaler 

Variabler 

27

Goto 

Label 

Connect 

Return 

Parametrar 


Noder 

GotoLabel 

Namn 

TrapNamn 

Label 

Expression (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

ProcedureCall 

Parameterlist (vektor) 

Literaler 

Variabler 

Parametrar (från en annan sändande rutin) 

Procedurnamn 

FuncCall 

Raise 

Retry 

TryNext 

Exit 

Parameterlist (vektor) 

Literaler 

Variabler 

Parametrar (från en annan sändande rutin) 

Funktionsnamn 

Expression (vektor) 

Noder 

Literaler 

Variabler 

Parametrar 

Radnr 

Radnr 

Detta är vilka noder som strikt sett finns i analysverktygets AST, med avseende på just 

analysdelen, samt de mest intressanta attributen till dessa noder. Observera att i t. ex Assignnodens 

högerled kan det ligga noder, men inte alla typer av noder, 

analysdelen av analysverktyget kontrollerar dock inte vilken nodtyp som ligger där. En 

kontroll att detta är riktigt har nämligen redan skett i den lexikala analysen. En intressant 

egenskap finns i t. ex högerledet i en assignsats. Det kan betraktas som ett uttryck, Expression. 

28

Det är i strikt bemärkelse inte en nod här. Jag anser inte att det måste vara så då 

analysprogrammet i det här avseendet har lägre krav än en kompilator och dess semantiska 

analys, se avsnitt 4.1. Det finns t. ex inget krav på att hålla reda på prioritet mellan operander. 

Operander finns för övrigt inte alls med här. När man analyserar "Noder", "Literaler", 

"Variabler" och "Parametrar" i avsedd vektor i Assignnoden, så sker det på ett systematiskt 

sätt där analysprogrammet kan behöva bearbeta exempelvis funktionsanrop och dess typ av 

nod. Allting i högerledet måste vara initierat för att vänsterledet ska kunna bli det också. Det 

hade kunnat gå att utelämna konstanter som t. ex siffran 1 i exemplen i början av avsnittet 4.4. 

4.5 Traversera noder, analysalgoritm 


Analysprogrammet loopar sig fram genom sitt AST som beskrivs generellt i pseudokoden i 

4.6. Topnoden håller moduler som i sin tur håller rutiner. Noderna för dessa heter i tur och 

ordning TopNode, Module och RoutineDefNode. Har den kommit fram till main rutinen, 

eller, en trap, så påbörjas analysen av en programflödesväg, se även avsnitt 3.2.1. 

RoutineDefNode håller alla satser och kommandon som inte ligger innanför block, i t. ex en If 

sats. 

Vilka vägar programflödet tar vid kommando noder beskrivs i kapitlen nedan. 

I samband med den lexikala analysen har inte bara ett AST byggts upp, utan även en standard 

symboltabell, se avsnitt 5.5.4. I den finns bland annat alla rutiner representerade, vad de heter, 

typ (funktion, procedur, trap), räckvidd och radnummer mm. Denna information är behjälplig 

när programflödet gör hopp genom t. ex funktionsanrop. I symboltabellen finns också alla 

typer av variabler registrerade, lokala som globala. Har de inte tilldelats direkt vid 

deklarationen så registreras de först som oinitierade. 

4.5.2 Iteration 

När en programflödesväg i Rapid går in i en Whilenod så utvärderderas först villkorsdelen. 

Dess olika delar ligger i en lista (vektor), t. ex så motsvaras uttrycket a 

a och b måste i det här läget vara initierade, konstanten 1 behöver naturligtvis inte analyseras 

och hade egentligen inte behövt finnas i listan. Det kan även ligga noder i listan, t. ex en 

funktionsanropsnod. Analysprogrammet analyserar i så fall den, se avsnitt 4.5.4, särskilt det 

som gäller parameteröverföring, tillståndet för dessa i den sändande rutinen skickas med i en 

egen struktur i analysprogrammet. De mottagande parametrarna finns däremot i 

funktionsanropsnoden. 

Villkorsdelen för Whilenoden påverkar alltid symboltabellen för det fortsatta programflödet. 

När programflödet når Fornoden registreras först den eventuella loopvariabeln som initierad i 

symboltabellen. Därefter sker samma sak i tur ordning för delarna From och To. Step kan 

däremot inte antas med säkerhet köras något varv. I regel så räknar Step bara upp eller ned 

loopvariabeln, som alltså är initierad i det här läget. 

Symboltabellen påverkas alltid av de nämnda delarna av Fornodens huvud för fortsättningen 

av programflödet. 

Därefter utvärderas alltså satsdelen, det gäller både för While och For. Där ligger 

kommandonoderna i en lista för While respektive och For. I programanalysens synpunkt så 

ligger dom i ett block, vilket inte är svårare att analysera än satser i en rutin. Efter att listans 

alla element gåtts igenom så återställs alltid symboltabellerna till läget som var efter 

29

villkorsdelen (huvudet), och innan satsdelen. De eventuella initieringar av variabler som skett 

i satsdelen är nämligen inte säkra, se gärna avsnitt 3.4 som resonerar kring 

programflödesekvationer för denna analys. Att de beaktas överhuvudtaget beror på att de är 

intressanta just inom loopkroppens kod. 

4.5.3 Selektion 

Först utvärderas villkorsdelen i If, CompactIf och Test-noderna vilket sker på samma sätt som 

i motsvarande för While. Observera dock listorna av undernoderna ElseIf respektive Case. 

Inverkan på symboltabellerna blir också lika som vid While:s villkorsdel, d v s total. Till 

skillnad mot för loopar så finns dock här flera olika vägar, eller olika satsdelar som var och en 

måste analyseras. Analysen av dessa vägar startar med en symboltabell som ser likadan ut för 

alla. När alla vägar är analyserade jämkas symboltabellerna samman och initieringar som skett 

i samtliga kommer att gälla för den symboltabellen som ska gälla efter t. ex en If-nod. Detta 

gäller när någon programflödesväg måste tas och finns beskrivet i avsnitt 3.5 och tabell 3.2. 

Om ingen satsdel någonstans måste köras, återställs helt enkelt symboltabellen till det som 

den var strax efter villkorsdelen. Se tabell 3.3. 

4.5.4 Funktionsanrop 

Analysprogrammet anropar en särskild rutin som letar upp funktionen i symboltabellen och 

programmet. I symboltabellen finns även information om på vilket radnummer den är 

deklarerad. I den underrutinen i analysprogrammet stegas Rapid funktionens noder och satser 

igenom. 

Analysprogrammet skickar en struktur med alla Rapidparametrar och tillståndet för dom till 

rutinen stepthroughfunction, strukturen skickas sedan vidare till den anropade rutinen och 

talar där om huruvida parametrarna är initierade eller ej. Den anropade rutinen genomgår 

alltså en kontextkänslig analys. Även recorddatatyper skickas på exakt samma sätt. 

En förutsättning för om den sändande funktionens parametrar ska kunna uppdateras, eller som 

är intressant i det här examensarbetet, initieras, är givetvis att rätt typer av variabler är 

inblandade. Har den mottagande funktionens variabler deklarerats som IN ska detta inte ske 

(se avsnitt 2.4.4). Funktionen stepthroughfunction får tillbaka en uppdaterad symboltabell för 

varje sats som den kör, när alla noder (satser) är bearbetade jämförs de sändande och 

mottagande parametrarna. Om parametertyperna är de rätta så kommer de sändande 

parametrarnas bakomliggande variabler att initieras, om de inte redan är det. Detta sker med 

hjälp av den i avsnitten tidigare nämnda parameterstrukturen. 

Om den anropade funktionen inte finns i symboltabellen så är det en digital funktion (se 

avsnitt 2.4.5). Man kan därefter ställa in om man vill anta att eventuella parametrar ska 

uppdateras (d v s, de tilldelas i den digitala funktionen) eller om man vill att de inte ska göra 

det. En grundförutsättning för detta är parametrarna som man skickat är av typen INOUT. 

Väntekommandon är digitala funktionsanrop eller proceduranrop, se nästa avsnitt. Om det 

också visar sig att dessa inte är acceptebla samt att det är en trap som utlöst 

programflödesvägen så ska analysprogrammet rapportera det som ett fel. Observera att här 

måste det inte vara säkert att väntekommandot körs vid exempelvis selektion. Det räcker att 

möjligheten finns för att analysprogrammet ska rapportera det som ett fel. 

4.5.5 Proceduranrop 

Förfarandet med proceduranrop skiljer sig inte mycket från funktionsanrop. Men dessa kan 

givetvis inte fungera i högerledet i en tilldelningssatts. Att syntaxen skiljer sig något i vid 

30

anrop av procedurer spelar i det här läget egentligen ingen roll, eftersom den lexikala analysen 

redan är avklarad och det abstrakta syntaxträdet redan skapat. 

4.5.6 Rekursivitet 

Exempelvis rekursiva funktioner (som är tillåtna i Rapid) skulle kunna bli ett problem för 

analysprogrammet. Samma funktion skulle kunna analysera sig själv gång på gång, alltså 

evighetsloopa. Samma sak skulle kunna ske om en eller flera rutiner ligger mellan anropen till 

sig själv i programflödet. Därför är en spärr satt att en rutin inte får analysera sig själv i sitt 

fortsatta programflöde, utan analysen bara fortsätter med nästa kommando. Häri ligger i 

princip en begränsning i den kontextkänsliga analysen, se avsnitt 4.5.4, vissa möjliga 

parametervärden till vissa funktionsanrop kanske aldrig blir utvärderade. Däremot kommer 

fortfarande all Rapidkällkod att bearbetas under analysen minst en gång, fast alltså möjligtvis 

inte i alla kontexter. 

4.5.7 Goto 

Vid Rapidkommandot Goto så dirigerar analysprogrammet programflödesvägen till den 

efterföljande identifieraren, här labeln, genom att söka upp vart den finns i Rapidprogrammet. 

Även labels varhelst de är deklarerade, finns i symboltabellerna, även om dessa främst är till 

för variabler som kan initieras etc. Lablarna kunde även ha haft en egen struktur, som 

dessutom inte skulle behöva uppdateras efterhand. 

Programmet kollar alla satser efter där labeln är deklarerad tills den aktuella rutinen tar slut 

eller gör Return. Därefter fortsätter programflödesanalysen till satser efter Gotoanropet. 

Observera att symboltabellen från Gotoanropet skickas med som parameter till 

analysprogrammets underrutin gotoLabel, samt att den i en uppdaterad variant returneras 

tillbaka. Det är inte tillåtet i Rapid att hoppa in loopar, eller satslistor innanför block över 

huvud taget, med hjälp av Goto. Det hade komplicerat traverseringen av noder i alla beskrivna 

fall, inklusive detta. 

4.6 Traversering av AST i analysprogrammet 

If, For, While, Funktionsanrop, Assign mm har varsin en egen nod. Assign består av ett 

vänsterled som tilldelas, token :=, och ett högerled med den förhoppningsvis givna 

informationen. Till skillnad mot de övriga noderna, med undantag av funktions och procedur 

anrop till digitala rutiner i vissa fall, kan även assign initiera variabler. Notera dock att det 

först är viktigt att kolla att allt i högerledet (som kan innehålla undernoder, identifierare och 

rena literaler) är helt intakt beträffande initiering. I Appendix finns hela analysprogrammets 

arbetssätt beskrivet som pseudokod. Denna ska inte förväxlas med den riktiga Javakod som 

analysprogrammet består av, och är inte är ett tvärsnitt av den riktiga koden, mycket är 

bortskalat, men principen är motsvarande för hur det abstrakta syntaxträdet traverseras för att 

hitta intressanta egenskaper i Rapidprogrammens källkod. Observera att mer komplexa noder 

som t. ex For också har undernoder, dessa är From, To och Step samt räknaren som i och för 

sig inte är en nod, i huvudet. Dessutom består loopkroppen av en lista med kommandon, som 

är noder. Synen på initieringar som sker inom en komplex nod är olika efteråt beroende på typ 

av nod samt om programflödet garanterat går igenom någon del eller inte gör det. Detta 

förklaras schematiskt i avsnitt 3.4. 

31

Alla moduler stegas igenom, på jakt efter mainrutinen och trapar i loopen innanför den. 

Därefter kollas kommandona, vilka är noder. Dessa kan vara direkt underställda rutinerna 

under traversering, eller finnas inom ett block, t. ex i satsdelen i en If-sats. I pseudokoden i 

Appendix hänvisas ofta enligt //Run a routine with code “if command is assign then {“ 

etc. vilket i själva verket avser ett rekursivt anrop i analysprogrammet. Rutinen som sköter 

allt detta i verkligheten, rekursivt anropad eller ej, behöver dock inte alla yttre loopar eftersom 

man redan har greppat rätt nod. 

I Assign kontrolleras först allt i högerledet, vilket kan bestå av literaler (siffror, strängar, 

boolska variabler), identifierare och funktionsnoder. Högerledet betraktas i själva verket som 

ett uttryck (i vilket allt måste vara initierat). Hur uttryck undersöks finns beskrivet i början av 

kapitlet 4.5.2. Identifierarna, och huruvida dom är initierade, finns lagrat i den symboltabell 

som används då. Den nedre delen efter den innersta loopen beskriver hur identifierare i 

vänsterledet kan bli initierade i symboltabellen i fallet Assign. Kontroll av initering och 

initiering i sig sker under samma (och enda) fas av traverseringen av AST. Däremot ligger 

kontrollen av att programmet inte går in i vänteläge (om en trap har startat 

programflödesvägen) i ett eget pass i den verkliga källkoden. Det hade fungerat att ha den i 

samma fast det hade blivit lite rörigare. Ett väntekommando är alltid en digital rutin (se avsnitt 

2.4.5) och hittas under traversering i funktionsanrop och proceduranrop. 

32

5. Lösning - Parser 

5.1 Inledning 

För att kunna analysera Rapidkällkodsfiler krävs ett verktyg/program som förstår språket 

Rapid, och som kan bygga upp ett abstrakt syntaxträd, AST (se avsnitt 4.3) samt analysera 

programflödet i detta. Detta analysprogram är fullt möjligt att programmera från grunden, fast 

ett enklare och mer strukturerat sätt är att använda någon av de så kallade kompilatorkompilator 

verktyg som redan finns. Dessa tar in en fil med regler för språket, i det här fallet 

Rapid, och översätter det till en kompilator skrivet i ett vedertaget programspråk som i de 

följande nämnda fallen C++ och Java. Sker en ändring i regelfilen ändras C++ eller 

Javakoden. Det är också möjligt, och menat, att man ska kunna ändra den utkommande C++ 

eller Javakoden. Möjligheterna för analys av det abstrakta syntaxträd, som JavaCC också har 

möjlighet att skapa, är mycket större i ett bredare språk som Java. 

5.2 Verktyg 

5.2.1 Yacc-Lex 

Yacc och Lex är ett av de vanligaste kompilator-kompilator verktygen, dess filer kan efter 

installation läggas in i projekt i t. ex Visual C++ 6.0 projekt. Det går sedan att 

ställa in så Visual C++ från .yac och .lex generarar C-kod av dessa innnan övrig 

kompilering av projektet sker. I Lex sker den lexikala analysen, i Yacc den 

syntaxiska och grammatiska. I Yacc går det att lägga in semantiska aktioner samtidigt 

som icke terminaler i grammatiken konsumeras. Ett exempel: 

functions : functions function {fprintf(stdout, "Func"); $$ = 

connectFunctions($1,$2);} 

| function {fprintf(stdout, "Func"); $$ = $1;} 

Dels kommer skärmutskrifter att ske, dels sker funktioner som är ett led i att bygga upp ett 

AST. Dubbla dollartecken är uttryckets vänsterled, dollartecken + siffra är vilken plats i 

högerledet som avses. I lexfilen så definierar man tokens för själva språket, dessa är i vissa 

fall intuitiva, men i vissa fall inte. Så här kan definitionen för en kommentars-token se ut t. ex: 

COMMENT "!""/"*([^*/]|[^*]"/"|"*"[^/])*"*"*"\n" 

Inte så begriplig alltså. En annan nackdel med Yacc-Lex, eller Bison-Flex som gratis 

varianten heter av dessa, är att såväl den genererade koden för den lexikala analysen, som den 

grammatiska, är tämligen obegriplig. Man är alltså nästan helt hänvisad till Yacc-filen när 

man vill utveckla och ändra i sin kompilator eller analysprogram. Därför övergavs ansatsen 

med Yacc-Lex till slut för det här examensarbetet. 

33

5.2.2 Javacc-Inledning 

Verktyget JavaCC är namngivet på grund av att det producerar fullständigt ren javakod samt 

att det är en kompilator-kompilator. Det är från början konstruerat av Sriram Sankar och 

Sreeni Viswanadha [Sankar, Viswanadha]. 

JavaCC är ett kommandorad-baserat verktyg. Det tar en regelfil som parameter och ut får man 

den parser som man vill ha. Valet av kompilator-kompilator för detta examensarbete kom till 

slut att bli JavaCC, det har enligt min mening en enklare regelstruktur än Yacc-Lecc, samt att 

den allra största delen av regelfilen för Rapid var gjord redan tidigare av examensarbetarna 

Kalle Gustafsson och Ilja Alaoja på MDH, för en annan Rapid och ABB relaterad uppgift. 

[Gustafsson, Alaoja, 06]. 

5.2.3 Regler-Input 

En viktig sektion i regelfilen och som ska komma tidigt är möjligheterna till olika options, ett 

exempel på två av dessa: 

options 

{ 

LOOKAHEAD = 4; 

IGNORE_CASE = true; 

} 

LOOKAHEAD står för hur många tokens som i det här fallet Rapidkompilatorn ska se i 

förväg i en regelstruktur. Det är inte alltid uppenbart för en parser (som detta i grunden är) 

vilken väg den ska ta. Av flera möjliga vägar kan minst två inledas med samma token(s). Ju 

kortare parsern ska se framåt ju snabbare blir den å andra sidan. IGNORE_CASE är givetvis 

om språket i sina nyckelord och identifierare ska skilja på stora och små bokstäver, det gör 

inte Rapid. Efter det kommer en sektion i filen, innanför nyckelorden: 

PARSER_BEGIN(MyParser) 

//Javakod 

och: 

PARSER_END(MyParser) 

Innanför dessa nyckelord kan man skriva ren javakod. Kalle Gustafsson och Ilja Alaoja 

började med att generera import-fil-direktiv, vilket man i och för sig också kan lägga till i den 

utkommande filen MyParser.java sedan. Fördelen med att lägga till dom direkt i regelfilen är 

att de alltid kommer att finnas vid en ny generering av javafiler, dessa filer kommer 

naturligtvis inte ihåg hur dom såg ut förra gången vilket kan leda till att man måste göra om 

samma saker flera gånger när man arbetar med JavaCC. Det viktigaste innanför 

PARSER_BEGIN och PARSER_END är klassdeklarationen om själva Parsern, den ska heta 

likadant som i direktiven. I det här fallet kan deklarationen se ut så här: 

class MyParser { 

. . . 

// generated parser is inserted here. 

} 

Här kan man lägga till egen kod efter hur den egna parsern ska agera. Man får en 

34

konstruktorprototyp och konstruktor, i det här fallet ser den förstnämnda ut enligt: 

public MyParser(java.io.InputStream stream) { 

this(stream, null); 

} 

JavaCC kommer sedan också att skapa en rutin för varje icketerminal bland reglerna. Dessa är 

med andra ord de tillåtna tokens, t. ex if som inledningen på en sats, vid varje ställe i 

Rapidgrammatiken. Den fil som åsyftas i konstruktorns parameter är den källkodsfil som ska 

parsas, i det här fallet i Rapid. Först nu är vid framme vid den grammatiska delen av JavaCC:s 

förväntade regelfil. Grammatiken, eller "Produktionen av reguljära uttryck" [CollabNet, 07] 

består av fyra olika delar i JavaCC, TOKEN, SPECIAL_TOKEN, SKIP och MORE. För att 

bygga en parser som ska klara ett språk av Rapids svårighetsgrad räcker det med SKIP och 

TOKEN. SKIP är tecken och teckensekvenser som ska ignoreras. Ett exempel på en SKIPsektion 

som ignorerar radbrytningstecken: 

SKIP : 

{ 

"\n" 

} 

Exempel på TOKEN, som är byggstenarna i själva språket: 

TOKEN : 

{ 

 

| 

| 

} 

Vad vi vet om det här presumtiva programspråket är att det accepterar uttrycken TRUE och 

FALSE, samt att radbrytningstecken inte betyder någonting, vilket också gäller om man 

blandar stora och små bokstäver, samt att det kollar fyra tokens framåt vid den grammatiska 

produktionen. Efter den lexikala analysen är det dags för den syntaktiska, själva reglerna. Så 

här börjar den i Rapidfallet: 

Node input() : 

{Node n; TopNode ret; String tImage;} 

{ 

{ 

ret = new TopNode(0); 

tImage = getToken(2).image; 

} 

( 

n = moduleDeclaration(tImage) 

{ 

ret.modules.add(n); 

tImage = getToken(2).image; 

} 

)* 

 

{ return ret; } 

} 

35

Node är fördefinierad i JavaCC, den är här själva roten i AST:s. input kommer verkligen att 

skapas som en parameterlös funktion i den utkommande javakoden. Observera hur likt 

JavaCC är riktig programmering. Tack vara *-tecknet så kan flera moduler hakas på topnoden. 

Lika intutiv är regeldefinitionen av identifierare: 

String identifier() : 

{String ret;} 

{ 

.................. 

.................. 

return ret; 

.................. 

} 

Endast ett fåtal regler ingår i denna JavaCC-funktion, som talar om att det ska vara token 

IDENT vilken i sin tur egentligen bara säger att det kan vara nästan allt annat än ett 

Rapidnyckelord. Tillbaka till dom boolska variablerna, som är en av tre literaler, t.ex för 

användning i högerledet vid tilldelning: 

void literal() : 

{} 

{ 

| | 

} 

literal kommer att skapas som javaprocedur, ingen programmering läggs till på JavaCC-nivån 

utöver kontroll av icketerminlernas automatgenererade rutiner (se samma stycke ovan). Dessa 

är dock inte det minsta intuitiva och näst intill omöjliga att modifiera om man vill det. 

Observera att typkontroll vid t. ex tilldelning, inte ligger inom den syntaktiska regelstrukturen. 

Så är det i alla kompilatorer vad jag vet. 

36

5.2.3 Output 

Tre javafiler kommer att skapas utifrån regelfilen. En av dessa är en sammanfattning över 

vilka tokens som man kan använda, en hanterar den lekikala analysen, och i en sker själva 

parsningen samt att AST byggs upp. Så här ser tidigare nämnda literal funktion ut den 

sistnämnda 

static final public Vector literal() throws ParseException { 

Vector v = new Vector(); 

if (jj_2_61(4)) 

{ 

jj_consume_token(NUM_LITERAL); 

v.add(token.image); 

} 

else if (jj_2_62(4)) 

{ 

jj_consume_token(STRING_LITERAL); 


} 

else if (jj_2_63(4)) 

{ 

jj_consume_token(BOOL_LITERAL); 


} 

else 

{ 

jj_consume_token(-1); 

throw new ParseException(); 

} 

return(v); 

} 

Observera att den skapades (av Kalle Gustafsson och Ilja Alaoja) som en procedur, void, men 

eftersom dess värde var intressant för den här uppgiften ändrades det till en Vector, där olika 

datatyper kan läggas. Hade typkontroll varit intressant för den här parsern skulle man kunna 

lägga även typen i vektorn v som returneras. Icke terminalernas funktioner, t. ex jj_2_62(4), är 

svåra att modifiera och det rekommenderas knappast heller. Men på ett ställe har jag faktiskt 

styrt om vägen för dessa. Det handlar om när installerade datatyper figurerar (se avsnitt 2.3.5). 

Dessa finns inte specificerade i regelfilen eftersom Rapid inte anger vilka de exakt är. 

5.3 AST från Parser 

5.3.1 Skapas under parsning 

Det går som beskrivits i avsnitt 4.3 och 4.4 att returnera noder tillbaka vid parsning och 

konsumering av tokens. När ett statement konsumeras kan tolv olika noder returneras i 

Rapidgrammatiken. Dessa har delvis samma attribut men också olika. If-noden har t. ex en 

Vektor med uttryck för den väg som programmet i truescenariot. Detta kan i sin tur vara andra 

If-noder eller andra. If-noden har liksom alla noder heltals datatypen Line, samt att dom flesta 

37

har även Column. Noden ProcedureCallNode skickar bland annat sina sändande parametrar 

medan noden RoutineDefNode skickar sina mottagande. Det är helt avgörande för analysen att 

ta reda på huruvida dessa är initierade. 

5.3.2 Analys av AST 

Det AST som en korrekt parsning ger, under förutsättning att rätt noder returneras vid rätt 

terminaler i grammatiken, är ett träd som börjar med själva programnoden. Ett enklare 

programspråk skulle ha sina subrutiner (och globala variabler mm) direkt under 

programnoden, Rapid har moduler och sedan rutiner. Det är kompilator-kompilatorprogrammerarens 

ansvar att varje nod innehåller tillräcklig information för att lösa den 

aktuella uppgiften. Man kan givetvis göra så att ny information lagras under parsning till AST. 

Vill man ha typkontroll t. ex så måste man observera när datatypen konsumeras och spara den 

i en symboltabell (se avsnitt 5.5.4). 

Vill man som i det här examensarbetets uppgift analysera programflöden bör man loopa fram 

till den rutin som ett sådant kan starta i, t. ex main. Är det istället den semantiska analysen 

som är intressant ska allt analyseras metodiskt från grunden. Lämpligtvis skickas hela 

trädstrukturen med noder till en ny separat källkodsfil, här heter den AnalyzeTree.java. Till 

samma fil bör även symboltabellen, som man också bör göra upp parsning, skickas. Den bör 

till skillnad från trädet kunna uppdateras under analysens gång. Har den kompilator, eller vad 

man vill göra, konfigurationsmöjligheter, ska dessa också skickas med. 

5.4 Analysprogrammet - Användning 

5.4.1 Exekvera analysprogrammet från Windows (och andra operativsystem) 

Man kör analysverktyget för Rapidkod genom att köra filen Rapid.jar som ligger i biblioteket 

dist på det stället som zipfilen för det här examensarbetet packats upp. Jarfiler behandlas på 

samma sätt som exefiler i Windows även om körmenyn inte listar dom om man väljer 

"Program". Programmet tar inga inparametrar från körmenyn eftersom det har ett grafiskt 

användargränssnitt. Man kan givetvis också dubbelklicka på Rapid.jar i utforskaren. Självklart 

måste Java vara installerat på den aktuella datorn för att detta ska fungera. För att köra 

programmet under olika former av Unix kan man via ett terminalfönster först bläddra fram 

biblioteket där Rapid.jar ligger, och sedan skriva java –jar Rapid.jar så går programmet 

igång. 

5.4.2 Konfigurera analysprogrammet beträffande waitstate 

Öppna filen waitforcommandointraps.txt en texteditor. Den består av tre sektioner nämligen 

enligt exemplen: 

ALWAYS_WARN 

WaitDO 

WaitDI 

END 

Hittar den något kommando, procedur eller funktionsanrop, som finns med i listan i 

programflödesvägen så kommer varning att ges. Detta sker bara om programflödesvägen 

kommer ifrån en trap (se avsnitt 3.2.4). Konfigurationsfilen är inte positionsberoende 

38

eträffande kolumner. Parametrar eller semicolon ska inte vara med, stora eller små bokstäver 

är inte avgörande. 

WARN_IF_NOT_TIMEOUT_SETTED 

ReadStr 

ReadBin 

END 

Dessa kommandon kan accepteras i trapars programflödesväg under förutsättning att 

timeoutparametern är satt. Ett exempel på det: ReadBin(globNavChannel\Time:=0.5);. 

MAXIMUM_TIMEOUT_ACCEPT_IN_SEC 

0.5 

END 

Den tredje korta sektionen. Exemplet med ReadBin kommer nu att passera utan varning. 

5.4.3 Definiera installerade datatyper 

För atomiska datatyper som inte är fördefinierade så är det bara att lista vilka det är i filen 

instaleddatatypes.txt, en för varje rad, vill man kommentera något om det, inled raden med 

utropstecken. Om programmet ger ifrån sig ett "Parse error on line X" meddelande under 

körning kan det mycket väl vara för att det på den raden finns en datatyp som inte finns med i 

filen. I filen instaledrecorddatatypes.txt kan man lista installerade recorddatatyper, hanteringen 

av dess medlemmar är inte klar ännu. I instaledaliasdatatypes.txt är det meningen att man ska 

lista installerade aliasdatatyper, om man nu har någon sådan i sitt Rapidprojekt. 

5.4.4 Ändra i analysprogrammets kod 

I Source Packages och kan man öppna filen Rapid.java i Netbeans. Denna 

fil innehåller det grafiska gränssnittet. I dess källkod byggs även .prg samt en .pre fil upp, den 

senare innehåller globala record och alias-deklarationer. I paketet bluefield finns källkoden 

finns resten och nästan all källkod för analysprogrammet. De två största filerna är 

RapidParser.java, som sköter allt utom programflödesanalysen på AST, det sker i 

AnalyzeTree.java. Avsnitt 5.5 och i viss del även 5.6, ger stöd åt om man vill komma igång 

med egen programmering i analysprogrammet, samt är givetvis i sig en del av lösningen. 

5.5 Analysprogrammet - Programmering 

5.5.1 Input till programflödesanalys 

Input till programflödesanalysen i filen AnalyzeTree.java är framför allt noden tree av typen 

TopNode. Åtkomst till modulerna i den finns via .modules. Konstruktorn i filen visar hur man 

därefter når rutinerna i dessa. Vidare kan man se hur uttrycken och variabler mm i dessa. 

Observera att det är fritt fram att skapa räknare över såväl moduler, rutiner, uttryck osv, fast 

man är inom en redan existerande loop, förutsatt att en ny loopvariabel används givetvis. 

Övrig intressant information till programflödesanalys beskriver sig själva i AnalyzeTree:s 

konstruktor. 

39

5.5.2 Detektering av waitstate 

Endast de rutiner som är trapar, eller som är anropade i en orsakskedja utifrån en trap, är 

intressanta här. Information om de är connectade, vilka endast kan vara intressanta vid en 

inställning i programmet, finns redan. Uttryck efter uttryck bearbetas genom 

checkcommandnode, här är scenariorna med procedurecallNode och functioncallNode 

inressanta. De intressanta riskkommandona som beskrivs i avsnitt 1.4 är ju sådana anrop till 

digitala anrop. observera dock att de sistnämnda även kan ligga inom assignnoden. Självklart 

kan dessa även finnas inom t. ex while:s satser, men de har redan anropats från den via 

checkcommandnode då. Känns namnet på rutinanropet igen med de väntekommandon som 

varnats för blir det en varning (se avsnitt om Konfigurera analysprogrammet beträffande 

waitstate). 

5.5.3 Detektering av oinitierade variabler 

I checkcommandnode:s kontroll av exempelvis assignnoden så ser vi att assignnodens 

högerled består av en vektor v där såväl noder, uttryck, literaler som identifierare kan finnas. 

För att ta identifierarna som exempel så kollas att inga sådana används om de inte är 

markerade som initierade i symboltabellen. Notera att här kan analysprogrammet stöta på 

såväl parametrar som lokala som globala variabler, och dessa kan inte behandlas på precis 

samma sätt, mer om detta senare. 

5.5.4 Symboltabeller – Beskrivning 

Symboltabeller används i alla kompilatorer och förmodligen alla analysverktyg som detta. De 

innefattar, liksom här, såväl rutiner som variabler etc. I kompilatorer är en av 

huvudanledningarna typkontroll, här är det att hitta oinitierade variabler. I många kompilatorer 

skapar man en ny symboltabell för varje rutin, samt en global. Här skapas inte nya 

symboltabeller på det kriteriet, utan istället kan den dela sig i flera om det dyker upp separata 

programflödesvägar, mer om detta i avsnitt 3.2.2. Symboltabellen i analysprogrammet, 

klassen SYmbolTable, innehåller framför allt medlemmarna Symbol i en länkad lista, denna 

har följande privata medlemmar: 

global (boolean) 

block (string); 

type (string); 

name (string); 

assigned (boolean); 

value (value); 

line (int); 

I filen SymbolTable.java finns en rad funktioner för att lägga till symboler, läsa utifrån olika 

sökkriterier mm. Den enklaste rutinen är konstruktorn som helt enkelt skapar en tom länkad 

lista med symboler. 

5.5.5 Lokala symboler före globala 

Funktionen getSymbol finns i två utföranden, en som tar den boolska parametern global och 

en utan. I den senare kollas först om den angivna symbolen finns och är lokal, d v s blocket 

stämmer överens med det som man skickar in, om inte, kollas efter globala, d v s blocket har 

ingen betydelse. Detta eftersom lokala variabler i Rapid, går före, eller gömmer, globala. 

Samma gäller i funktionen setSymbolAssigned i SymbolTable.java. 

40

5.5.6 Variabel eller parameter 

I en lokal Rapidrutin kan analysprogrammet lika gärna stöta på en inskickad parameter som en 

lokalt eller globalt deklarerad variabel. Jag har valt att lösa det genom att om symboltabellen 

inte finner denna symbol initierad så kollar det i t. ex assignnodens scenario i AnalyzeTree 

genom funktionen isparameterandassigned om det kan vara en initierad parameter. Den 

Rapidrutin som programflödesvägen nått fram till har fått en struktur 

SendingRoutineParameters skickad till sig, om den inte är null finns där lagrat information om 

den sändande rutinens parametrar och om dessa är initierade. 

5.5.7 Recordar i symboltabellen 

Recordar komplicerar bilden en aning när man söker efter oinitierade variabler, inte minst om 

de skickas som parametrar. Jag har valt att lösa det så att dels kan en hel record existera i 

symboltabellen, och den kan vara markerad som initierad där. Men om den eftersöks och inte 

finns så kan även enstaka recordmedlemmar existera där, och dessa kan ha initierats. Ska t. ex 

en lokal instans av en record tilldelas en global kollar analysprogrammet först om hela den 

finns som initierad i symboltabellen, om inte söker den upp varje medlem i denna och är alla 

initierade var för sig, t.ex genom tilldelning, så är det okej. Det omvända scenariot finns också 

att en lös recordmedlem med punktoperatorn t. ex finns i högerledet av en assignsats. 

Analysprogrammet kollar då först om hela recorden finns som initierad, om inte så om just 

den recordmedlemmen är det. 

5.5.8 Behov av ny symboltabell i programflödesvägen 

Detta behov uppstår t. ex när en if-node dyker upp i programflödesvägen. Innan 

analysprogrammet träder in i den så sparar den symboltabellen som den ser ut innan på en fil 

som indikerar att det är en "if-symboltabell" samt att radnumret ingår i filnamnet också. Att 

spara den i en variabel hade varit mer praktiskt, men på grund av "call by reference" problem, 

(se avsnitt 1.7) i Java så hade den gamla symboltabellen hela tiden en tendens att uppdateras 

även den i det som nu beskrivs. Inför If-nodens olika vägar, true samt eventuellt else och olika 

else if villkor så börjar man på nytt med den gamla symboltabellen. 

5.5.9 Test av flera symboltabeller beträffande en symbols värde 

Genom att deklarera en instans av klassen SymbolTableVector och lägga alla uppdaterade 

symboltabeller (en för varje programflödesväg i t. ex if-satsen) och sedan genom dess 

medlemsfunktion makeonesymboltable så summeras vad som har hänt totalt i alla if-satsens 

delar. Om t. ex en variabel tilldelats i alla så ska den också markeras som initierad efter det att 

if-satsen avverkats. Denna kontroll sker på globala variabler samt variabler som finns just i 

den aktuella subrutinen där if-satsen finns. 

5.6 Felmeddelanden och varningar 

5.6.1 Felmeddelanden beträffande lexikal analys 

Som belyses i avsnitt 5.2.3 så kan analysprogrammet träda in i kodraden: throw new 

ParseException(); om den inte lyckas konsumera någon av icketerminalerna innan. Någon av 

konstruktorerna i den av JavaCC producerade filen ParseException.java kommer att köras 

beroende på vilken information som finns tillgänglig vid felet i Rapidkoden. Ett vanligare 

händelseförlopp är att när analysprogrammet försöker konsumera en eller flera icketerminaler, 

och misslyckas, så konsumerar den en Token genom att köra funktionen jj_consume_token i 

RapidParser.java med ingångsvärdet -1. När detta inte lyckas så körs i sin tur 

41

generateParseException vilken bygger ihop en mer fullständig bild av Token, förväntad 

Token och radnummer. Detta går att använda i ParseException.java, som nu mest är ett skal, 

om man är ute efter att göra en mer fullödig kompilator. 

5.6.2 Varningar beträffande waitstateanalys 

Genom att deklarera en instans av klassen GetTrapTimeWarningCommands som läser in den 

editerbara filen waitingcommandosintraps.txt så får analysprogrammet information genom två 

vektorer och en float (vilken är högst tillåtna väntetid för vissa kommandon) om vilka 

kommandon som den ska varna för om de dyker upp i trapars programflödesväg. Klassen 

Writeerrormessage skriver felmeddelanden men exakt samma felmeddelande (text, rad samt 

eventuell kolumn) kan inte förekomma två gånger. 

5.6.3 Varningar beträffande oinitierade variabler 

En förutsättning för att programmet ska undersöka om en variabel, persistance etc är oinitierad 

är först och främst att man verkligen har stött på en variabel. Först undersöker programmet om 

det nått en nod av något slag istället, t. ex en funktionsanrops-nod. Observera att det i den 

funktionsanrops-noden kan finnas variabler att undersöka i en eventuell parameterlista, men 

den kontrollen sker så att säga ett varv senare. 

Därefter går isVarPersConstAssigned i SymbolTable.java igång. SymbolTable har givetvis 

inget problem med att rätt symboltabell används eftersom det är en instans av denna som 

används. En instans av GetRecordAndAliasDatatypes.java skapas för i den finns strukturer 

med deklarerade recordar i Rapidprogammet. Dessa var tvungna att skapas innan som ett slags 

förkompilering. Dessutom kollas vilka installerade datatyper som finns (se avsnitt 2.3.5). 

Dessa strukturer kan man få nytta av om det inte är en vanlig atomisk variabel, programmet 

kollar nämligen om det är så att hela recordinstansen är markerad som initierad om det är så 

att den eftersökta recordmedlemmen inte är det, då är allt okej och ingen varning kommer att 

ges. 

Dessutom kan det omvända scenariot gälla, att man stött på en instans av en hel 

recordstruktur, och den inte finns i symboltabellen som initierad, men alla dess medlemmar är 

markerade som det. Då kommer ingen varning att ges för att recordvariabeln är oinitierad. 

Återigen skriver klassen Writeerrormessage felmeddelandet om den ska det. 

5.6.4 Varningar beträffande oinitierade parametrar 

Om ovanstående misslyckas kan det bero på man stött på en parameter, symboltabellen 

uppdaterar inte per automatik sådana vid t. ex funktionsanrop. Funktionen 

isparameterandassigned i AnalyzeTree.java går igång och undersöker en instans av strukturen 

SendingRoutineParameters (se avsnitt 4.4.4) där information finns om den sändande rutinens 

motsvarande variabels tillstånd. Inte bara atomiska variabler etc undersöks utan även recordar, 

på samma sätt som beskrivits i föregående avsnitt. 

5.6.5 Tillvägagångssätt i motttagande rutin 

Isparameterandassigned i AnalyzeTree.java har givetvis namnet på parametern som den ska 

undersöka. Den har även som framgår av parameterlistan en vektor parameterlist med 

Rapidparametrar för den mottagande rutinen i den ordning som dom är deklarerade. Nu kan 

den aktuella Rapidparametern få ett nummer som kan matchas mot motsvarande i strukturen 

som är en instans av SendingRoutineParameters, och huruvida den hann bli initierad innan 

den skickades vidare via funktions eller proceduranrop. 

42

5.6.6 Sändande funktioner, procedurer och trapar 

Innan ett funktionsanrop börjar stega igenom funktionen så byggs en instans av strukturen 

SendingRoutineParameters upp. Som framgår av dess medlemsfunktioner så kan såväl 

atomiska datatyper, och huruvida dom är initierade eller ej, samt recordstrukturer läggas till i 

den. Observera att funktionsanropsnoden, där detta sker just nu, också måste undersöka om 

huruvida det är en egen inparameter som ska skickas, och inte bara anta att det är en variabel. 

Den är då i sig att betrakta som en mottagande rutin. Inte bara instansen till 

SendingRoutineParameters skickas med till stepthrougfunction i AnalyzeTree, utan också 

symboltabellen vid det aktuella tillfället. 

5.7 Orsakskedjor 

Som nämnts i föregående avsnitt kan den sändande funktionen i sin tur vara en mottagande 

funktion osv. Dessa anropskedjor kan vara hur långa som helst. För att kunna blicka bakåt i 

orsakskedjan så har den struktur som kopplar samman mottagande och sändande rutiners 

parametrar, SendingRoutineParameters, en egen instans av sig själv. Är den inte null när den 

kontrolleras, samt att det finns ett riktigt rutinnamn, så ger analysprogrammet förslag på i 

vilka rutiner som den sändande parametern kan behöva initieras. Analysprogrammet vet om 

huruvida en parameter är oinitierad eller ej, även långt fram i orsakskedjan, fast det säger inte 

exakt i vilken rutin i kedjan som den behöver initieras i, utan ger som sagt förslag på detta. 

5.8 Skal och vidareutveckling för andra uppgifter 

Som beskrivits i avsnitt 1.3 är detta program inte ett skal och inte byggt först som ett skal för 

att sedan låta just implementeringen av sökandet efter oinitierade variabler och vänteläge i 

trapar, ta vid. Men det är ändå ganska bra strukturerat och flera nyttiga klasser och 

programstrukturer går att använda för att lösa andra uppgifter också. T. ex är det inte svårt att 

presentera felmeddelanden, symboltabellerna innehåller medlemmar för värden, även om 

dessa inte direkt används nu. I AnalyzeTree.java finns flera självbeskrivande funktioner och 

procedurer även om det också är långa loopar med flera villkor. Det är bra om man följer 

indenteringen med nedåtpil-tangenten vid dessa, för att komma till rätt nivå. Alla uppgifter för 

ett statiskt analysprogram, vilka det finns exempel på i avsnittet ”Relaterat arbete” nedan, 

bygger dessutom på metoden med programflödesanalys på ett upprättat abstrakt syntaxträd, 

AST, vilket således naturligtvis finns tillgängligt även i detta analysprogram. 

43

6. Relaterat arbete 

6.1 Inledning 

Det finns ett antal statiska analysprogram för kontroll av källkods korrekthet, för bland annat 

C, C++ och Javakod. Tre av dessa presenteras i varsitt avsnitt nedan. Informationen är 

hämtad från ”White paper” från respektive företags hemsida. Som en introduktion till det här 

examensarbetet läste jag även översiktligt rapporter från Stanford University, som också givit 

upphov till Coverity, som beskrivs i 6.2. Dessa handlade bland annat om hur stora 

operativsystem (t. ex Linux) behandlar resurser som är gemensamma för hela systemet. Dessa 

kan behöva ha lås, och då gäller det att hålla reda på om detta är satt eller inte, och om det är 

rätt i så fall. Metoden är inte helt olik den som för att hitta oinitierade variabler i det här, och 

följande refererade arbeten. 

6.2 Coverity 

6.2.1 Historik 

Coverity är ett företag som kommit med ett antal kommersiella verktyg för statisk analys av 

C/C++ kod. Det började egentligen som en del i att få fram mer säker och kvalitativ kod på 

Stanforduniversitetet och blev från och med 2002 ett eget kommersiellt företag. Bland de som 

använder Coveritys verktyg finns bland annat NASA, McAfee, Palm och Sun. 

6.2.2 Statisk analys av C/C++ program 

Coveritys verktyg är kan man säga är en parallell kompilator till den som koden ligger i. Den 

är helt oberoende av denna och det går att installera Coverity till många olika C/C++ 

kompilatorer och plattformar, och framförallt är det enkelt att installera Coverity, kanske för 

att det är helt oberoende av miljö och kompilator. ”Coverity Prevent begins its analysis by 

actually compiling the code, using the same process to understand the code that a compiler 

uses to generate object files and executables.” [Coverity05] (s. 14) Genom att kompilera 

koden först undviker Coverity de ofta felaktiga varningar, och ännu värre, missade varningar, 

som andra statiska verktyg kan ge upphov till. 

6.2.3 AST-struktur 

Coverity skapar inte oväntat ett abstrakt syntaxträd, AST, samt flödesgrafer och anropsgrafer. 

Det resulterar sedan i ett VBE (Virtual Environment Build) som i sin tur resulterar i en 

funktionsmodell. Efter att onödiga delar av funktionsmodellen tagits bort, det kan t. ex vara 

rutiner som aldrig anropas, så börjar analysen. 

6.2.4 Interprocedurell granskning 

Felaktig och riskabel kod sträcker sig ofta över flera olika rutiner, men det är inte omöjligt att 

analysera när man har ett AST och som i det här fallet en funktionsmodell. Se följande 

exempel från Coveritys hemsida: 

44

100 void buggy(char *p) { 

101 my_free(p, 1); 

102 *p = ‘\0’; 

103 } 

104 

105 static int total_alloc; 

106 

107 void my_free(void *p, int sz) { 

108 if(sz > 0) 

109 free(p); 

110 total_alloc -= sz; 

111 } 

[Coverity05] (s. 16) 

Coverity ser att att proceduren buggy anropar my_free och att den andra inparametern är 1. 

Den kommer då att gå in i truedelen på rad 109 och stryka den andra inparametern pekaren p 

ur minnet, tyvärr så används den senare i buggy på rad 102. Coverity kommer att rapportera 

det här felet, fast hade 0 varit den andra parametern på rad 101 hade inget fel rapporterats. 

6.2.5 Egenskaper och fel som upptäcks 

Coveritys verktyg upptäcker bland annat användning av oinitierade variabler, deadlocks, dvs 

två uppgifter, t.ex i två olika trådar väntar på varandra och ingen blir gjord, användning av 

pekare som avallokerats, att free av pekare körs två gånger och felaktig allokering av minne 

mm. 

6.2.6 Likheter med Rapid analysprogrammet 

En av de egenskaper som Coveritys verktyg kollar efter är som nämnts oinitierade variabler. 

Precis som Rapid-analysprogrammet så bygger det upp ett abstrakt syntaxträd och tar sedan ut 

programflödesvägar ur det. De anropsgrafer som nämns ovan är kan sägas vara en del av 

programflödesvägarna här. Den databas över fel som verktygen kan hitta har en viss, men 

begränsad likhet i den editerbara fil som finns över vilka kommandon som inte alls, eller 

under vissa omständigheter inte bör, komma i trapars programflödesväg, se avsnitt 3.2.4. 

6.2.7 Skillnader gentemot Rapid analysprogrammet 

Coverity är inriktad på C/C++ kod vilken inte är överförbar till Rapid. Dess verktyg Coverity 

prevent och Coverity extend är inriktat på betydligt fler programmeringsfel med undantaget att 

de inte tar ut speciella programflödesvägar för event (i Rapid trap) och särbehandlar vissa 

kommandon där. Coverity kan eliminera vissa programflödesvägar om dess uppställda villkor, 

t. ex if-satser, aldrig kan uppnås. Rapid-analysprogrammet analyserar alla programflödesvägar 

och tar inte ställning till hur villkoren ser ut för dessa. 

6.3 Klocwork 

6.3.1 Likheter med Coverity 

Klocwork bygger liksom Coverity upp ett abstrakt syntaxträd med noder över kommandon. 

Precis som Coverity kan det utvärdera om vissa programflödesvägar är möjliga att ta för att 

sedan utesluta andra. [Fisher,07] (sida 4). Klocworks analysverktyg går att applicera på C/C++ 

men också Java. 

6.3.2 Fel som upptäcks 

6.3.2.1 Denial of Services 

Detta gäller serverprogram, förut kanske DCOM Automation Object, numera kanske oftare 

.NET services eller Java-servlets. Funktioner som kan nås via t. ex Internet kan missbrukas för 

45

att överbelastas serverdatorn. Detta t. ex genom att vektorer som skickas som inparametrar 

inte avallokeras under alla omständigheter, varefter minnet tar slut. 

6.3.2.2 Minnesfel 

Nullpekare får inte under några omständigheter behandlas som om de vore inte vore det. 

Ibland är det inte uppenbart att en pekare har avallokerats och satt till NULL i C/C++. Det kan 

t. ex ske genom att en annan pekare tilldelats den pekare som sedan anropas, och den 

förstnämnda har satts till NULL innan. Den typen av fel upptäcks av Klocwork. 

6.3.2.3 Fel i arrayer och vectorer 

Följande exempel från Klocworks WhitePaper får illustrera: 

void f(unsigned char* stream) 

{ 

unsigned char buf[32]; 

memcpy(buf, stream + 1, *stream); 

… 

} 

”In this trivial case, the author has made a fundamental assumption about the cleanliness of 

the incoming data, coupled with an architectural assumption about the range of that data. If 

this function is used in an environment open to attack, for example to process marshaled data 

from another process or server, or even from a file that is subject to injection on the user’s 

system, the attacker could cause considerable stack corruption simply by exploiting the fact 

that the code will happily copy up to 255 bytes into a buffer able to hold only 32” [Fisher,07] 

(s. 7) Med detta exempel syftar Fisher på en svaghet i ett serverprogram som kan utnyttjas av 

en hackare för att krascha programmet eller i värsta fall datorn. Men det är lika illa om det 

finns i ett vanligt program på den lokala datorn eftersom andra programmerare i ett projekt, 

eller samma person, kan utnyttja proceduren ofrivilligt på fel sätt. Klocworks analysverktyg 

upptäcker alltså i vilket fall programmeringsfelet. 

6.4 Polyspace 


Många av Polyspace:s kunder finns inom fordonsindustrin. Bilar mm innehåller många 

datorsystem och program, oftast skrivna i C. Polyspace motiverar sitt verktyg och sina 

rekommendationer för god programmering gentemot dessa med att kostnaderna för att testa Ckoden 

annars skulle bli mycket högre, samt att säkerheten för passagerarna i motorfordonet 

kommer att bli högre med bättre och säkrare kod i systemen. 

6.4.2 Likheter med Coverity och Klocwork 

Polyspace kallar sitt verktygs metod för semantisk analys. ”Semantic Analysis relies on a wide 

base of mathematical theorems that provide rules for analyzing complex dynamic systems 

such as software applications” [Hote,01]. Polyspace hittar genom dessa precis som Coverity 

oinitierade variablers användning och som Klocwork möjliga fel i arrayer och vektorer, och 

dessutom tack vare ”worst case scenario” analys möjliga overflow och underflow i datatyper. 

Självklart genomför det en interprocedurell analys eftersom programflödesvägar sträcker sig 

genom dessa i t. ex C. 

6.4.3 Underflow och Overflow i datatyper 

46

Signed och Unsigned datatyper agerar helt olika om dess värde överstiger max för datatypen, 

t.ex heltal. Unsigned ger ju ingen information om dess värde är negativt eller positivt, alla 

förutsätts vara positiva. En osignerad datatyp får värdet 0 vilket kan vara en indikator sedan på 

att något gått fel, medan en signerad börjar om i sin negativa ände vilket kan ge upphov till 

svåra fel senare i programmet. Det är fritt fram att blanda signerade och osignerade datatyper i 

C, och dessutom kan man efter en matematisk operation spara resultatet från en eller flera 

större datatyper i en mindre, vilket i sin tur kan ge programkörningsfel senare i programmet. 

Polyspace:s verktyg kan hjälpa till att skapa säkrare behandling mellan olika datatyper: 

”As opposed to Ada, strong typing is not part of C, but adopting type checking rules helps maintain a 

clearer design” [Lalo, Barriault,05]. Detta är också något som Motor Industry Software 

Reliability Association, MISRA, har i sina riktlinjer. Polyspace utför också ”värsta tänkbara 

scenario” beträffande vilka värden signerade och osignerade datatyper kan få i ett C-program. 

Som beskrivits tidigare kan särskilt signerade datatyper skapa fatala problem vid overflow. 

6.4.4 Division med 0 

Division med 0 är inte tillåtet inom programmering. Ett uttryck som t. ex: 

A = x / (x-y); 

[Deutsch, 03] är riskabelt vilket Polyspace Verifier rapporterar. Ett villkor om x skiljt från y 

bör läggas till. 

47

SLUTSATSER 

Att utveckla ett statiskt analysprogram för programspråket Rapid visade sig vara fullt möjligt. 

Ibland nämns liknande verktyg för t. ex C-kod som statiska verktyg för dynamisk kod, vilket 

förklarar begreppet något. Analysprogrammet har samma metod som de som rapporten 

refererar till i det relaterade arbetet. Ett abstrakt syntaxträd byggs upp bestående av noder för 

kommandon och olika programflödesvägar, i det här fallet alla nåbara, testas på detta. De 

eventuella programkörningsfel som analysprogrammet i det första skedet skulle, och är, 

inriktat på är att upptäcka är: 

Om Rapid-programmen riskerar att gå i tidsbestämt eller ej tidsbestämt vänteläge om en trap, 

att jämföra med event, är starten i programflödesvägen, samt att upptäcka om oinitierade 

variabler används. Det är fullt möjligt att utveckla analysprogrammet så att det upptäcker 

andra, ej önskade egenskaper, i Rapid-programmen också. 

Att upptäcka trapars vänteläge visade sig vara relativt enkelt. Att upptäcka oinitierade 

variabler var inte så svårt heller så länge det handlade om atomiska datatyper, t. ex i Rapid 

num, bool och string. Sammansatta datatyper kom att komplicera uppgiften, samt när 

variabler skickas som parametrar mellan rutiner. Inte heller detta har emellertid varit omöjligt 

att genomföra, dock så är inte test av olika elements initiering i arrayer implementerat i detta 

verktyg. Analysprogrammet hittar de egenskaper som de söker efter, av nämnda anledning 

med arrayer samt att vissa rekursiva anrop kan exkluderas, kanske möjligtvis dock inte till 100 

procent i alla Rapidprojekt. De mer omfattande arbeten som refereras till i det relaterade 

arbetet, utger sig inte heller för att göra det. 

Något som kan tyckas vara ett problem vid testning av framför allt ett riktigt Rapidprojekt av 

filer, är att analys av detta tar ganska lång tid, i det här fallet över tre minuter på en normal 

dator. Detta beror bland annat på att programflödesvägarna är väldigt många och långa i det. 

En annan anledning kan vara att analysprogrammet, efter inläsning av en regelfil i kompilatorkompilator 

verktyget JavaCC, är skrivet i Java. Samt givetvis att min egen programmering 

och analys av det abstrakta syntaxträdet, kanske i alla lägen inte är optimal. I en tidigare 

version av analysprogammet så tog detta Rapidprojekt dock den dubbla tiden att analysera, så 

jag har lagt ner tid på att försöka effektivisera analysprocessen. 

Analysprogram av källkod kräver per definition mycket datorkraft, det är därför som 

uppkomsten av dessa har dröjt så länge som fram till 2000-talet, för själva algoritmen och 

metoden för dessa har funnits ända sedan 1970-talet. Men de orsaker som nämnts i föregående 

stycke kan också bidra extra till den tid som analys av ett stort och komplext Rapidprojekt kan 

ta. Detta verktyg kanske i vissa fall passar bäst att använda vid en slutlig kontroll av Rapid 

programmerade projekt, så kallade TASK:s. 

48

REFERENSER 

[Rapid overview] “ RAPID_overview.pdf”, “Revision C” 

[Rapid kernel reference] “RAPID_kernel_reference.pdf” “Revision C” 

[Aho, Sethi , Ullman, 88] Alfred V.Aho, Ravi Sethi, Jeffrey D.Ullman, 

“Compilers”, Addison-Wesley, 1988. 

[Gustafsson, Alaoja, 06] Kalle Gustafsson, Ilja Alaoja, “Lastanalysator till 

Rapid”, C-uppsats, Mälardalens högskola, IDE, 

Västerås 

http://www.mdh.se/ide/eng/msc/index.php?choice=sh 

ow&id=0495 , 2006 

[Sankar, Viswanadha] Sriram Sankar, Sreeni Viswanadha, JavaCC, 

https://javacc.dev.java.net/, 

http://www.cs.stanford.edu/~sankar, 

http://www.cs.albany.edu/~sreeni 

[CollabNet, 07] CollabNet ,”JavaCC [tm] Grammar Files“, 

, 

2007. 

[Coverity, 05] Coverity, ”Coverity_tech_whitepaper”, San 

Francisco, USA, , 2005. 

[Fisher, 07] Gwyn Fisher, Klocwork Inc, 

”AutomatedSourceCodeAnalysis.pdf”, (s. 4), 

, 2007. 

[Hote, 01] Chris Hote, General Manager at Polyspace 

Technologies Inc, ”Semantic_Analysis”, (s. 5), 

, 2001. 

[Lalo, Barriault, 05] Marc Lalo, Steve Barriault, Polyspace Technologies 

Inc,”PolySpace-white-paper-automotive”, (s. 5), 

, 2005. 

[Deutsch, 03] Alain Deutsch, Chief Technical Officer at Polyspace 

Technologies Inc,” Static_Verification”, (s. 4), 

, 2003. 

49

APPENDIX 

for(i=0;i

} 

} 

} 

else if command is compactif then 

{ 

Compactif compactif = routine.command.get(k); 

compactifscenario(compactif, symboltable, actual_routinename); 

} 

//End of “compactif” scenario, now functioncall scenario 

else if command is functioncall then 

{ 

Functioncall functioncall = routine.command.get(k); 

functioncallscenario(functioncall, symboltable, actual_routinename); 

} 

//End of functioncall scenario, now procedurecall 

else if command is procedurecall then 

{ 

Procedurecall procedurecall = routine.command.get(k); 

procedurecallscenario(procedurecall, symboltable, actual_routinename); 

} 

//End of functioncall scenario, now goto scenario 

else if command is goto then 

{ 

Goto goto = routine.command.get(k); 

symboltable = gotolabel(goto.labelname, symboltable, 

actual_routinename); 

//This function searches for a label command associated with the 

//name goto.labelname, and steps the code there until routine 

//is ended. 

} 

//End of goto scenario, now raise scenario 

else if command is raise then 

{ 

Raise raise = routine.command.get(k); 

Symboltable savedsymboltable = symboltable.save; 

for(l=0;l>= raise.statementlist.size();l++) 

{ 

Command command = raise.statementslist.get(l); 

//Check this command similar to “command” is checked above! 

//Run a routine with code “if command is assign then {“ etc. 

} 

gotoerror(symboltable); 

//This procedure searches for a error command in the same routine 

//and runs it to routine ends. 

symboltable = savedsymboltable; //The changes of initiations are not 

//safe. 

} 

51

void assignscenario(Assign assign, Symboltable symboltable, 

String actual_routinename) 

{ 

errorfound := false; 

for(l=0;l

void whilescenario(While while, Symboltable symboltable, 


{ 

for(l=0;l>=while.condition.size();l++) 

{ 

conditionpart = while.condition.part.get(l); 

//Here every part of conditionpart of the expression is checked 

//Could be almost anything in there. 

if conditionpart is literal then 

{ 

//No problem! 

} 

else if conditionpart is identifier then 

{ 

if check_if_assigned(conditionpart, symboltable, 

actual_routinename) then 

//No problem! 

else 

report_error(conditionpart, actual_routinename); 

} 

else if conditionpart is function then 

{ 

if step_through_function(functionname*, symboltable) then 

//No problem! 

else 

report_error(functionname*, 


} 

} 

//End of while condition checks. Now the body 


for(l=0;l>=while.statementslist.size();l++) 

{ 

Command command = while.statementslist.get(l); 



} 

symboltable = savedsymboltable; 

//End of while statements body checks 

} 

53

void forscenario(For for, Symboltable symboltable, 


{ 

symboltable.assign(for.loopvariable.name, actual_routinename); 

for(l=0;l>=for.from.size();l++) 

{ 

frompart = for.from.get(l); 

//Here every part of “from” is checked 


if frompart is literal then 

{ 

//No problem! 

} 

else if frompart is identifier then 

{ 

if check_if_assigned(frompart, symboltable, 


//No problem! 

else 

report_error(frompart, actual_routinename); 

} 

else if frompart is function then 

{ 


//No problem! 

else 



} 

} 

//End of from checks. Now the “to” part of for expression 

for(l=0;l>=for.to.size();l++) 

{ 

topart = for.to.get(l); 

//Here every part of “to” is checked 


if topart is literal then 

{ 

//No problem! 

} 

else if topart is identifier then 

{ 

if check_if_assigned(topart, symboltable, 


//No problem! 

else 

report_error(topart, actual_routinename); 

} 

54

} 

else if topart is function then 

{ 


//No problem! 

else 



} 

} 

//End of “to” checks. Now the “step” part of for expression 

if check_if_assigned(stepvariable.name, symboltable, actual_routinename) 

then 

//No problem! 

else 

report_error(stepvariable.name, 


//End of for header checks. Now the body 


for(l=0;l>=for.statementslist.size();l++) 

{ 

Command command = for.statementslist.get(l); 



} 

symboltable = savedsymboltable; 

//End of for statements body checks 

55

void testscenario(Test test, Symboltable symboltable, 


{ 

for(l=0;l>=test.test.size();l++) 

{ 

testpart = test.test.part.get(l); 

//Here every part of testpart of the expression is checked 


if testpart is literal then 

{ 

//No problem! 

} 

else if testpart is identifier then 

{ 

if check_if_assigned(testpart, symboltable, 


//No problem! 

else 

report_error(testpart, actual_routinename); 

} 

else if testpart is function then 

{ 


//No problem! 

else 



} 

} 

//End of test condition checks. Now different cases in test scenario 


Symboltablevector symboltablevector = new Symboltablevector(); 

for(l=0;l>=test.caselist.size();l++) 

{ 

Case case = test.caselist.get(l); 

for(m=0;m>=case.size();m++) 

{ 

Command command = case.statementslist.get(m); 



} 

symboltablevector.add(symboltable); 

} 

if(test.default == null) 

symboltable = savedsymboltable; //The changes of initiations are not safe. 

else 

{ 

Default default = test.default.get(l); 

for(m=0;m>=default.size();m++) 

{ 

56

} 

} 

Command command = default.statementslist.get(m); 



} 


symboltable = symboltablevector.makeonesymboltable(); 

//A variable that is initiated in all ways is initiated even after 

//the “test” expression 

57

void ifscenario(If if, Symboltable symboltable,String actual_routinename) 

{ 

for(l=0;l>=if.condition.size();l++) 

{ 

conditionpart = if.condition.part.get(l); 




{ 

//No problem! 

} 


{ 



//No problem! 

else 


} 


{ 


//No problem! 

else 



} 

} 

//End of if condition checks. Now if statementlist 


Symboltablevector symboltablevector = new Symboltablevector(); 

for(l=0;l>=if.statementlist.size();l++) 

{ 

Command command = case.statementslist.get(l); 



} 


for(l=0;l>=if.elseiflist.size();l++) 

{ 

Elseif elseif = if.elseiflist.get(l); 

for(m=0;m>=elseif.size();m++) 

{ 

Command command = elseif.statementslist.get(m); 



} 


} 

if(if.else == null) 

58

} 


else 

{ 

Else else = if.else.get(l); 

for(m=0;m>=else.size();m++) 

{ 

Command command = else.statementslist.get(m); 



} 


symboltable = symboltablevector.makeonesymboltable(); 

//A variable that is initiated in all ways is initiated even after 

//the “if” expression 

} 

59

void compactifscenario(CompactIf compactif, Symboltable symboltable, 


{ 

for(l=0;l>= compactif.condition.size();l++) 

{ 

conditionpart = compactif.condition.part.get(l); 




{ 

//No problem! 

} 


{ 



//No problem! 

else 


} 


{ 


//No problem! 

else 



} 

} 

//End of compactif condition checks. Now compactif statementlist 


for(l=0;l>= compactif.statementlist.size();l++) 

{ 

Command command = compactif.statementslist.get(l); 



} 


} 

60

void functioncallscenario(Functioncall functioncall, Symboltable symboltable, 


{ 

if(symboltable.get(functioncall.name)!=null) //User defined function exist 

{ 

symboltable = step_through_function(functioncall.name, symboltable, 

actual_routinename, functioncall.parameters, symboltable) ** 

//This function loops to searched routine in a similar but independent 

//way like above 

} 

else //This is a digital, in Rapid predefined function 

{ 

if(trapiscalling) 

{ 

if(foundinwaitcommandarray(functioncall.name)==true) 

report_error(functioncall.name, actual_routinename, 

waitcommanderror); 

} 

for(l=0;l>= functioncall.parameters.size();l++) 

{ 

Parameter parameter = functioncall.parameters.get(l); 

if(parameter.type == INOUT && assumedigitalinitiate) 

{ 

symboltable.assign(parameter.name, actual_routinename); 

} 

} 

} 

symboltable.assign(functioncall.leftside.name, actual_routinename); 

} 

61

void procedurecallscenario(Procedurecall procedurecall, Symboltable symboltable, 


{ 

if(symboltable.get(procedurecall.name)!=null) //User defined procedure exist 

{ 

symboltable = step_through_procedure(procedurecall.name, 

symboltable, actual_routinename, procedurecall.parameters, 

symboltable) ** 

//This function loops to searched routine in a similar but independent 

//way like above 

} 

else //This is a digital, in Rapid predefined procedure 

{ 

if(trapiscalling) 

{ 

if(foundinwaitcommandarray(procedurecall.name)==true) 

report_error(procedurecall.name, actual_routinename, 

waitcommanderror); 

} 

for(l=0;l>= procedurecall.parameters.size();l++) 

{ 

Parameter parameter = procedurecall.parameters.get(l); 

if(parameter.type == INOUT && assumedigitalinitiate) 

{ 

symboltable.assign(parameter.name, actual_routinename); 

} 

} 

} 

} 

• * Funktionen step_through_function i pseudokoden returnerar här ett initerat, eller 

oinitierat värde. 

• ** Funktionen step_through_function i pseudokoden returnerar här istället den 

utkommande symboltabellen 

62

Statiskt analysprogram för Rapid - Mälardalens högskola

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?