Ytterligare ett steg mot realisering av SystemJ

Transkript

1 Ytterligare ett steg mot realisering av SystemJ Michael Hansson 27 april 2009

2 1 Abstract (Sammanfattning) 2

3 2 Förord 3

4 Innehåll 1 Abstract (Sammanfattning) 2 2 Förord 3 3 Inledning Problem Teori GALS - Globally Asynchronous Locally Synchronous Multi-processor scheduling SystemJ Signal Resolves TReK Verktyg JFlex - The Fast Scanner Generator for Java Beaver - a LALR Parser Generator JastAdd GraphViz - Graph Visualization Software Eclipse Apache Ant Subversion (SVN) JUnit Utvecklingsprocessen Planering Genomförande Kompilatorn för SystemJ FrontEnd Lexikalisk analys Syntaktisk analys Semantisk analys BackEnd Schemaläggning av signaler Generera Javakod med TReK Generera Javakod med TReK och optimerade reactions Undersökning Val av undersökningsmetod Testprogram Resultat Diskussion Arbetet Resultat - Slutsats Referenser 20 4

5 A SystemJ-kompilatorn 20 A.1 Checka ut projektet ifrån repository A.2 Exekvering A.3 SystemJ Syntax B Bilagor 20 5

6 Ytterligare ett steg mot realisering av SystemJ 3 Inledning Inbyggda system är den typ av elektroniska system som idag nyttjas mest till bearbetning av information. I de flesta elektroniska enheter som säljs t.ex. mobiltelefoner, diskmaskiner, TV, spisar, bilar, medicinsk utrustning, kameror, m.m. sitter det någon form av inbyggt system. Enligt Information Society Technologies (ITS), vilka är en grupp inom EU s teknologiska forskningsavdelning, så nyttjades år 2006 ca 98% av alla mikroprocessorer till inbyggda system (se [13]). Grafen i figur 1 visar ju inte längre än till 2001, men det räcker ju med att titta Figur 1: Grafen visar totalt antalet mikroprocessorer mellan och hur många av dem som sitter i vanliga PC (resten sitter i inbyggda system, enligt [13]). Grafen visar även antalet människor på jorden 2 under samma period i sitt egna hem för att få sig en uppfattning om hur detta teknikområde växer. Framför allt så får man kanske en uppfattning om hur viktigt utvecklingen inom inbyggda system är. 3.1 Problem Inbyggda system nyttjas ofta i kritiska system, där dom ställs mot väldigt höga krav. Exempel på sådana krav kan vara pålitlighet, säkerhet och tillgänglighet. En huvudfaktor, som påverkar flera av dessa kraven, är att inbyggda system ofta är beroende av batterier. Utvecklingen av batterier i jämförelse med utvecklingen av inbyggda system går betydligt långsammare, vilket skapar ytterligare krav på inbyggda system. Det kan vara krav som att de inbyggda systemen måste vara energisnåla, innehålla små program pga svårigheter med lagringsutrymmet, nyttja så lite resurser som möjligt för beräkningar, m.m. [6] Detta projekt kommer att fokusera på ett SLDL-språk (System Level Design Language) som kallas SystemJ. Programspråket, som ännu befinner sig på forskningsstadiet, är framtaget för att ge nya möjligheter inom mjukvaruutvecklingen för inbyggda system. Det kan t.ex. handla om att flera av de befintliga språken enbart kan hantera synkrona eller asynkrona processer. När man implementerar dessa två olika processer i olika utvecklingsmiljöer kan det 6

7 3.1 Problem Ytterligare ett steg mot realisering av SystemJ var svårt eller kanske t.o.m omöjligt att uppnå tillräckligt effektiv och tillfredställande kommunikation där emellan, vilket påverkar de krav som nämndes tidigare. I detta fall erbjuder därför SystemJ möjligheten att implementera och hantera dessa i samma utvecklingsmiljö, utan att mjukvaruutevecklaren behöver ta hänsyn till detaljerna kring kommunikationen, vilket skapar en både effektivare och där med mer tillfredställande mjukvara. Det enklaste sättet att hantera kommunikationen mellan processer är med dynamisk schemaläggning, dvs att varje process körs separat enligt ett schema som bestäms under exekveringen. I detta projekt ska vi undersöka om möjligheten till att slå samman processer på synkron nivå kan leda till ytterligare effektivisering. Min frågeställning för detta projektet blir därför: Genom att slå ihop synkrona, reaktiva 1 processer, går det att minska exekveringstid, nyttjande av minne och minimiera storleken på programmet? Eftersom det inte finns någon konkret testmiljö för simulering och där med undersökning, kommer SystemJ-programmen översätts till Javakod. Det finns ett Javapaket som kallas True Reactive Kernal (TReK) [4], vilket erbjuder SystemJ-funktionalitet i Java-miljö vilket kommer att nyttjas. Den genererade Javakoden kommer sedan att exekveras i en Java Virtual Machine (JVM). För att underlätta undersökningen kommer en kompilator för detta ändamål att konstrueras som kan översätta SystemJ-kod till Javakod och projektet är därför indelat i två delar. Del 1 Del 2 Skapa en FrontEnd för SystemJ Skapa en BackEnd som genererar Javakod med TReK Skapa en alternativ BackEnd som nyttjar TReK, men som sätter ihop flera synkrona reactions till en Undersöka om flera synkrona reactions som satts ihop till en är effektivare än att köra med separata, utifrån de egenskaper som omnämns i frågeställningen. Utvecklingen av kompilatorn finns beskriven i avsnittet Kompilator för SystemJ. 1 Med reaktiv menas att signaler har specifika egenskaper så som att dom ges möjlighet att få företräde före en annan signal och att en signal kan skicka information till flera processer 7

8 Ytterligare ett steg mot realisering av SystemJ 4 Teori 4.1 GALS - Globally Asynchronous Locally Synchronous Globally Asynchronous Locally Synchronous är en modell som bygger på att man fördelar bearbetningen av information över olika processer som arbetar på olika nivåer (global eller lokal). Globalt sker kommunikationen mellan två processer genom asynkron kommunikation, vilket är ett måste eftersom globala processer (även kallade klock-domäner) arbetar på olika processorer med olika klockfrekvenser. Lokalt, dvs i en klock-domän sker kommunikationen synkront, där alla processer arbetar med samma klockfrekvens. Fördelen med att fördela arbetet över denna modell jämfört med t.ex. en del tidigare modeller, där man globalt fördelar arbetet över synkrona processer, är att man t.ex. dels får ner förbrukningen av ström 3 och dels får en lättare struktur att arbeta med. Det finns ju dock även nackdelar och ett exempel på en sådan är att kommunikationen mellan de globala processerna blir ineffektivare då processer måste vänta på varandra. 4.2 Multi-processor scheduling 4.3 SystemJ SystemJ är ett nytt SLDL-språk 4. Framtaget för att bemästra en del av de hinder som idag finns inom inbyggda system. Det kan vara hinder som att flertalet befintliga språk endast erbjuder utvecklingsmöjligheter på asynkron eller synkron nivå, att kommunikationen mellan processer är väldigt komplext att implementera för utvecklaren i.o.m. att storleken på systemet är väldigt stort eller att kommunikationen mellan olika asynkrona processer inte är tillräckligt effektiv. Det omnämns två olika typer av nivåer ovan som behöver klargöras. Med abstraktionsnivå menas den nivå som programmeringsspråket ligger på och med bara nivå menas den nivå som koden arbetar på i systemarkitekturen dvs global eller lokal. SystemJ är baserad på GALS-modellen och tillsammans med att Java kombineras med en reaktiv paradigm, erbjuds en möjlighet att skapa komplex mjukvara som både arbetar på asynkron- och synkron nivå (se figur 2) utan att utvecklaren behöver ta hänsyn till detaljer kring kommunikationen mellan de olika processerna. [1] I SystemJ kallas reaktiva processer för reactions och denna term kommer att brukas från och med nu. För att ett programmeringsspråk ska bli mindre komplext på en högre abstraktionsnivå, krävs delvis mer komplexitet på en lägre abstraktionsnivå. Detta projekt inriktar sig mot den synkrona kommunikationen och på denna nivån yttrar sig komplexiteten genom att signalers status påverkar exekveringen. För att kunna beskriva hur signalen påverkar kommunikationen måste vi först redogöra för hur en signal fungerar. 3 Denna effektivisering av energiförbrukningen uppnås genom att man till de processer som inte körs, dynamiskt kan reglera strömförsörjningen [14] 4 System Level Design Language (SLDL) är en typ av språk där utvecklaren arbetar på väldigt hög abstraktionsnivå (sk. Systemnivå), utan att behöver ta hänsyn till detaljer i implementationen [1] 8

9 4.3 SystemJ Ytterligare ett steg mot realisering av SystemJ Figur 2: Bilden beskriver hur de olika processerna i SystemJ-modellen relaterar till varandra Signal En signal kan deklareras som antingen pure eller valued. pure innebär att signalen inte antar ett värde medans valued innebär att signalen antar ett värde. Detta ska inte beblandas med att signalen även har en viss status för varje tick 5. Statusen för varje signal är antingen PRESENT, ABSENT eller UNRESOLVED. Hädanefter kommer även termer som resolved och unresolved att användas. Med resolved menas att statusen för signalen är känd dvs att statusen är (ABSENT eller PRESENT ) och unresolved betyder då att statusen är okänd dvs (UNRESOLVED). För att skicka information via en signal, nyttjas SystemJ-kommandot emit, som dels på signalen sätter statusen till PRESENT och dels ev. ett värde under en tick. Detta i kombination med att SystemJ hanterar signalerna på klockdomän-nivå, betyder att en ny tick kan endast starta när alla signaler är resolved i alla reactions. Detta är en av anledningarna till att exekveringen påverkas, vilket i värsta fall kan leda till att programmet hänger sig. En annan anledning är att om vi sent i ett tick får reda på att att signalen är ABSENT eller PRESENT, så måste vi invänta denna status och exekveringstiden påverkas. Statusen för alla signaler sätts till UNRESOLVED i början av alla ticks Resolves I föregående avsnitt omnämndes två faktorer som påverkar exekveringen. Dessa faktorer kan dock motverkas/minimieras genom att man gör en analys av SystemJkoden och så tidigt som möjligt i en tick sätter statusen för en signal till AB- SENT för signaler som annars har statusen UNRESOLVED under en tick. Om signalen emitteras, dvs. statusen sätts till PRESENT och signalen ev. antar ett värde, behöver vi inte behandla signalen. För att kunna utföra denna analysen automatiskt nyttjas en sk. Control Flow Graph (CFG) 6. Det handlar om att följa flödet i exekveringen, dvs att hitta signaler som inte emitteras under en tick och sätta statusen till ABSENT 5 En tick är definitionen av det som exekveras mellan två 6 CFGn är ännu ett hjälpmedel ifrån skaparna bakom JastAdd, vilket nyttjas för att utföra sk. Control Flow Analysis. Mer om detta går att läsa i [3] 9

10 4.3 SystemJ Ytterligare ett steg mot realisering av SystemJ så tidigt som möjligt i samma tick. I denna analysen måste man ta hänsyn till loopar t.ex. while eller for, noder med grenar t.ex. if-then-else eller switch-case, men även specialfall med SystemJ-kommandona abort och suspend. abort och suspend fungerar nämligen så att exekveringen avbryts inte förrän vid nästa tick delimiter 7 (kommunikationen sker ju synkront). Detta kommer att beskrivas lite mer praktiskt när vi kommer till avsnittet Schemaläggning av signaler i beskrivningen av kompilatorn TReK För att kunna skapa SystemJ-program i en Java-miljö togs True Reactive Kernal (TReK) [4] fram. TReK är ett Javapaket som innehåller all grundläggade funktionalitet i SystemJ. Detta är det packet som kommer att nyttjas för simulering och utvärdering av SystemJ-kod i detta projekt. 7 Tick delimiter är det som avslutar en tick. I ystemj görs detta med komamndot pause 10

11 Ytterligare ett steg mot realisering av SystemJ 5 Verktyg I detta avsnitt presenteras verktygen. För respektive verktyg kan detaljer hittas på deras hemsidor, vilka är angivna som referenser. 5.1 JFlex - The Fast Scanner Generator for Java JFlex [12] är en skanner, vars syfte är att tolka tecken och skapa tokens (en symbol som representerar en teckenserie). 5.2 Beaver - a LALR Parser Generator Beaver [8] är en parser som genererar ett AST-träd 8 utifrån Context-Free Grammar (CFG), som är skrivna på Extended Backus-Naur Form (EBNF). Genom att sätta samman tokens ifrån skannern till sk. produktionsregler, kan programkod tolkas grammatiskt och AST-noder genereras. 5.3 JastAdd JastAdd [2] är en open-source, Java-baserad kompilator kompilator. Framtagen som ett hjälpmedel för att underlätta skapandet av en kompilator. JastAdd är navet i detta projekt när det gäller att ta fram kompilatorn för SystemJ. Verktyget erbjuder funktionalitet för att skapa objekt-orienterade AST-noder, analysera och transformera dessa noder samt lägga till diverse funktionalitet i AST-noderna. 5.4 GraphViz - Graph Visualization Software GraphViz [10] är ett verktyg som nyttjas för att rita upp grafer. Dessa grafer skapas genom att man skriver DOT-kod som sedan tolkas och en graf genereras. 5.5 Eclipse All utveckling kommer att ske i Eclipse [9]. Detta program erbjuder en interaktiv utvecklingsmiljö och är anpassat för externa verktyg som bl.a. Ant, Subversion och JUnit, vilket är väldigt praktiskt när det gäller utveckling av mjukvara Apache Ant Att bygga projekt med olika delar är oerhört tidskrävande så fort projekten börjar bli någorlunda stora. Ett effektivt hjälpmedel för detta är Apache Ant [7], som genom script kan utföra en mängd olika operationer med ett knapptryck. I detta projekt nyttjas Ant bl.a. till att sätta samman filer, exekvera JastAdd, kompilera alla klasser, m.m. 8 Ett AST-träd (Abstract Syntax Tree) är ett strukturerat sätt att representera kod på. Trädet består av noder, som kan bestå av inga eller flera barn. I detta projekt består ASTnoderna av klasser som autogenererats med JastAdd utifrån en specifikation 11

12 5.5 Eclipse Ytterligare ett steg mot realisering av SystemJ Subversion (SVN) Ett annat viktigt hjälpmedel är någon form av versionshantering. Jag har valt Subversion av det enkla skäl att vi nyttjar [5] som repository för projektet och där används SVN JUnit För all formell testning kommer JUnit [11] att nyttjas. 12

13 Ytterligare ett steg mot realisering av SystemJ 6 Utvecklingsprocessen Denna del ger en djupare bild av hur själva arbetet har genomförts. 6.1 Planering Upplägget och målet i från första början har varit en ambitiös inriktning genom hela projektet. Tyvärr måste jag dock säga att min förmåga att uppskatta tid för olika saker inte är jättebra. Jag känner dock inget enormt nederlag för det, då det åtskilliga gånger i flera kurser under utbildningens gång har poängterats att bra uppskattningar kräver erfarenhet och även de mest erfarna kan ha svårt att göra goda uppskattningar. Det betyder ju inte att det kan skilja hur mycket som helst mellan den uppskattade planeringen och den verkliga, utan jag anser fortfarande att arbetet har legat inom en rimlig ram. Efter en diskussion med min handledare så satte vi upp ett relativt tydligt mål att utgå ifrån. Med relativt menar jag att målet var beroende delmomenten, dvs vilka delmoment som hann utföras. Eftersom utgångspunkten visade sig vara lite väl ambitiös, så har planeringen förändrats under arbetets gång och där med har målet blivit tydligare. För att min handledare skulle ha en chans att hålla sig uppdaterad då vi befunnit oss på olika delar i landet, har jag även fört en dagbok på internet. 6.2 Genomförande Arbetet har försökts att hållas strukturerat genom hela genomförandet, men att ensam jobba med ett större projekt som detta gör att jag gärna tagit mig friheter genom att t.ex. tänja på gränserna och ibland tom. tagit avsteg ifrån den strukturella modellen. Jag har tydligt märkt att dessto mer jag tycker något är spännande, dessto mer tid lägger jag på det och dessto mindre tid blir det till andra aktiviteter, som i sin tur blir lidande. Själva framtagandet av kompilatorn, som har varit det primära, har skett genom små iterationer enligt figur 3. Själva arbetet har också delats upp i seg- Figur 3: Bilden beskriver hur en iteraton har sett ut under utvecklingsprocessen ment, enligt den uppdelning som är angiven i inledningen, dvs först har jag tagit fram en FrontEnd för SystemJ, där efter en BackEnd med TReK, osv. Med andra ord så har även arbetet på global nivå brytits ner i mindre iterativa delar. Specificering har inneburit att titta på den dokumentation som finns om SystemJ. Min handledare, som själv har bidragit en del till utvecklingen av 13

14 6.2 Genomförande Ytterligare ett steg mot realisering av SystemJ SystemJ, har varit en ovärderlig källa till information, så har det varit något oklarheter då har vi fört en diskussion om det. Design har för mig varit att bl.a. analysera hur TReK eller Control Flow Graph fungerar samt läsa in mig på manualen för JastAdd (se [2] för detaljer). För att kunna göra analys eller transformationer i AST-trädet innerhåller nämligen JastAdd funktionaltiet för att lägga till kod i AST-noderna. Implementation har gjorts uteslutande i Eclipse. I princip all kod har skrivits i sk. apsects (JastAdd-syntax), Beaver-kommandon eller JFlex-kommandon. Detta har gjort Eclipse har fungerat som en vanligt text-editior istället för ett kodningsverktyg. Eclipse erbjuder nämligen varken analys (lexikalisk, syntaktisk och semantisk) eller syntax highlighting för dessa kommandon, vilket har ställt högre krav på mig. Testning har delats upp i två kategorier, formell och informell. För FrontEnd har det tagits fram en formell test-suite, som kan testas med JUnit. Den formella testning i FrontEnd består av följande filer: TestAll.java - Söker upp alla filer i samma mapp som innehåller testcases. TestCaseOutput.java - Innehåller funktionalitet som gör att man kan matcha en input med en output i JUnit. I detta fall handlar det om att jämföra det som SystemJAnalzyer.java matar ut med en förväntad output. GrammatTest.java - Innehåller testcases för grammatiken SemanticTest.java - Innehåller testcases för semantiken SystemJAnalyzer.java - Innehåller olika funktioner för att analysera och testa SystemJ-kod. Testdatan för den formella testningen finns i FrontEnd/testdata, där den SystemJkod som skall testas finns i filer med ändelsen.sysj och det förväntade resultatet, som skapas när.sysj-filen matats genom SystemJAnalyzer.java, i filer med ändelsen.exp. I BackEnd har informell testning nyttjas. Detta för att det är extremt tidskrävande att skriva testfall för kodgenerering. Istället har de genererade Javafilerna analyserats, dels av Eclipses interna lexikaliska-, syntaktiska- och semantiska analysator för Java, men även av mig för att säkerhetsställa att SystemJkoden översätts korrekt. 14

15 Ytterligare ett steg mot realisering av SystemJ 7 Kompilatorn för SystemJ En kompilator är ett program som översätter kod ifrån en högre abstraktionsnivå till en lägre. För att förbättra strukturen och öka kompabiliteten hos en kompilator, så delas den upp i tre abstrakta steg; FrontEnd, Intermediate Code och BackEnd (i den ordningen). Genom att dela upp den på detta sätt kan man lättare anpassa kompilatorn t.ex. för en speciell plattform, utan att behöva skriva om hela kompilatorn. Intermediate Code är ett helt eget avsnitt och kommer inte att behandlas i detta projekt, utan här är BackEnd kopplad direkt till FrontEnd. SystemJ bygger på Java. Utvecklarna av JastAdd har tagit fram en fullständig kompilator för Java 1.5, skriven i Java, som har utvecklats genom att bl.a nyttja deras egna verktyg, dvs JastAdd, men även Beaver och JFlex har nyttjats. Java 1.5 FrontEnd är en grundpelare för SystemJ-kompilatorn och SystemJ FrontEnd läggs som en egen nivå ovanpå (se figur 4). SystemJ BackEnd är där emot inte beroende av Java 1.5 BackEnd, vilket också illustreras i figur 4 och kommer där med inte att nyttjas. Att bygga vidare på en befintlig struktur, i detta Figur 4: Bilden illustrerar hur SystemJ ligger som ett lager ovanpå Java. fall Java 1.5 FrontEnd, innebär en del fördelar. Exempel på sådana fördelar är att grammatiken och semantiken går att återanvända i SystemJ. JastAdd erbjuder funktionalitet för förädla AST-noderna i Java 1.5 FrontEnd, vilket bidrar till en tydlig och mer lättarbetad struktur i koden för kompilatorn. Med kompilatorn menas hädanefter hela SystemJ-kompilatorn med Java 1.4 FrontEnd, Java 1.5 FrontEnd (som bygger på Java 1.4 FrontEnd), SystemJ-FrontEnd samt SystemJ-BackEnd. 15

16 7.1 FrontEnd Ytterligare ett steg mot realisering av SystemJ Kompilatorns inre steg är illustrerade i figur 5 och förklaring till varje steg följer i kommande avsnitt. Figur 5: Bilden illustrerar hur kompilatorns inre steg är sammankopplade 7.1 FrontEnd Lexikalisk analys Lexikalisk analys går ut på att översätta en serie av tecken till en symbol (sk. token). I detta projekt nyttjas JFlex, ett verktyg som utifrån sk. regular expressions autogenererar en skanner som utför lexikalisk analys. Man brukar skilja på tre typer av symboler. Whitespace - Teckenserier som ska ignoreras, t.ex. mellanslag, tabbar, kommentarer. Non-Terminals - Teckenserier som inte är förbestämda, t.ex variabelnamn, konstanter. Terminals - Teckenserier som är förbestämda (nyckelord), t.ex. public, +, void. Eftersom vi bygger på Java 1.5 FrontEnd behöver endast nya nyckelord läggas till. 16

17 7.1 FrontEnd Ytterligare ett steg mot realisering av SystemJ Nyckelord signal channel emit sustain present await suspend abort trap exit reaction system output input send receive pause Beskrivning Nyttjas för att definerar en signal Nyttjas för att definerar en kanal Nyttjas till att på en signal sätta statusen till present och ev. ett värde under en tick Nyttjas till att sätta statusen för en signal till present för alla tick Nyttjas för att kolla om statusen för en signal är present Nyttjas för att vänta tills statusen för en signal blir present Nyttjas till att pausa nuvarande händelse om en specifik signal blir present Nyttjas till att avbryta en händelse om statusen för en specifik signal blir present Nyttjas till att definerar en fälla för en händelse i ett block Nyttjas till att hoppa ur blocket som är definerat för en fälla Nyttjas till att definera en synkron eller asynkron process Nyttjas till att definera klock-domäner och hur dessa kommunicerar Nyttjas till att definera en ut-signal/kanal Nyttjas till att definerar en in-signal/kanal Nyttjas till att sända data via en kanal Nyttjas till att ta emot data ifrån en kanal Nyttjas som tick delimiter Följade nyckelord är en sammansättning av de befintliga nyckelord som ingår i java. Nyckelord Beskrivning >< Nyttjas till att definera asynkron parallell kommunikation Nyttjas till att definera synkron parallell kommunikation Syntaktisk analys Steg två i kompilatorn är att analysera grammatiken (syntaxen) via syntaktisk analys. Mer konkret kan man säga att syntaktisk analys innebär att man analyserar strukturen av olika symboler för ett programmeringsspråk. Verktyget Beaver nyttjas till detta. Genom att definiera sk. produktionslagar, dvs kombinationer av Terminals och Non-Terminals, så autogenereras en parser som följer dessa lagar. Parsern i sin tur genererar ett AST-träd för en input-fil. JastAdd innehåller funktionalitet för att skapa klasser med attribut (för detaljer se [2]), som representerar AST-noderna. Grammatiken för SystemJ är definerat på Backus-Naur Form (BNF). För att grammatiken skall fungera med parsern (beaver) och även Java 1.5 FrontEnd, så behöver den skrivas om på Extended BNF-form. I detta skede har grammatiken, 17

18 7.2 BackEnd Ytterligare ett steg mot realisering av SystemJ delvis i samförstånd med min handledare men också pga att TReK stödjer det, utökats till att stödja komplexare uttryck. I definitionen för SystemJ är SystemJ-kommandona await, present, suspend och abort definerade så att dessa enbart beror på en signal. TReK stöjder dock uttryck för statusen på signaler, dvs man kan skriva t.ex. (Signal1 && Signal2), vilket innebär att både Signal1 och Signal2 måste ha statusen PRESENT, för att villkoret ska vara uppfyllt. Utöver den booleska operationen AND (&&) finns även OR ( ) och NOT (!). För en definition av grammatiken hänvisas till syntaxen för SystemJ i appendix Semantisk analys Det tredje och sista steget i FrontEnd är den semantiska analysen. Tidigare steg har endast handlat om att kontrollera så att olika tecken är skrivna i en speciell ordning. Här sker en djupare analys. Det mesta av denna analys handlar faktiskt om att hitta variabler, signaler, m.m. och kontrollera så att dom är deklarerade, att de operationer som utförs på dem följer de regler som finns t.ex. att typen av ett objekt nyttjas på ett korrekt sätt. Mer konkret innebär det att man kontrollerar så att t.ex. en numerisk operation endast får utföras om objektet är av en numerisk typ eller att en parameter som skickas med i ett metodanrop är av samma typ som metoden förväntas ta emot. I SystemJ kan det handla om att en kanal endast får ha en input och en output eller att receive endast kan vänta på kanaler. 7.2 BackEnd Schemaläggning av signaler Som nämndes i teoridelen, så påverkas exekveringen av SystemJ-kod bl.a. av statusen hos signaler. För att effektivisera kommunikationen på synkron nivå och motverka så att SystemJ-programmet fastnar i ett deadlock-läge, behöver en analys göras. Analysen går ut på att antingen bekräfta att alla signaler antingen emitteras (statusen för signalen sätts till PRESENT ) under en tick eller se till så att statusen sätts till ABSENT genom TReK-kommandot resolve så tidigt som möjligt under en tick. För att utföra denna analys nyttjas en Control Flow Graph (se [3] för detaljer). Denna graf läggs som en struktur ovanpå AST-trädet, där varje nod har en referens till båda nästa instruktion (s.k. successor) och föregående instruktion (s.k. predecessor) Generera Javakod med TReK Generera Javakod med TReK och optimerade reactions 8 Undersökning 8.1 Val av undersökningsmetod Simulering och undersökning kommer att ske i en. Den genererade Javakoden kommer att exekveras i en Java Virtual Machine, i Windows-miljö. Detta medför 18

19 8.2 Testprogram Ytterligare ett steg mot realisering av SystemJ att att eventuella förändringar mellan de olika testerna kommer att beskrivas relativt istället för definitivt, för att få en bättre uppfattning av resultatet. Resultatet kommer sedan att presenteras i en tabell. 8.2 Testprogram 8.3 Resultat 9 Diskussion 9.1 Arbetet 9.2 Resultat - Slutsats 19

20 Ytterligare ett steg mot realisering av SystemJ 10 Referenser Referenser [1] Z. S. Avinash Malik and P. Roop. Efficient compilation of gals language systemj. May [2] T. Ekman and G. Hedin. Internet, [3] E. M. o. T. E. Emma Nilsson-Nyman, Görel Hedin. Declarative intraprocedural flow analysis of java source code. LDTA08paper.pdf. [4] Z. S. Flavius Gruian, Partha Roop and I. Radojevic. The systemj approach to system-level design [5] Google. Internet, [6] P. Marwedel. Embedded System Design. Springer, P.O. Box 17, 3300 AA Dordrecht, The Netherlands, [7] A. A. team. Internet, [8] B. team. Internet, [9] E. team. Internet, [10] G. team. Internet, [11] J. team. Internet, [12] J. team. Internet, [13] I. S. Technologies. Internet, hardware.htm. [14] Z. Yu and B. Baas. High performance, energy efficiency, and scalability with gals chip multiprocessors. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 17(1):66 79, A SystemJ-kompilatorn A.1 Checka ut projektet ifrån repository A.2 Exekvering A.3 SystemJ Syntax B Bilagor 20