Abstract Worst-case exekvation time (WCET) analys handlar om att beräkna en exakt-som-möjligt bundet för den maximala tid genomförandet av ett program kan ta. Denna information är nödvändig för att utveckla säkerhetskritiska realtidssystem, t.ex. inom flyg- och bilindustrin. Med början i Chens, Moks, Puschners, Shaws och andras initiala arbeten i mitten och slutet av 1980-talet förvandlades WCET-analysen till ett väletablerat och levande forsknings- och utvecklingsområde inom akademi och industri. Det ökande antalet och mångfalden av hård- och mjukvaruplattformar och de pågående snabba tekniska framstegen blev drivkrafter för utvecklingen av ett brett spektrum av olika metoder och verktyg för WCET-analys. Precisionen, generaliteten och effektiviteten hos dessa metoder och verktyg beror i hög grad på uttryckligheten och användbarheten hos de anteckningsspråk som används för att beskriva genomförbara och ogenomförbara programvägar. I den här artikeln undersöker vi de anteckningsspråk som vi betraktar som formativa för fältet. Genom att undersöka och jämföra sina individuella styrkor och begränsningar med avseende på en uppsättning centrala kriterier ger vi en sammanhängande översikt över den senaste tekniken. Genom att identifiera öppna frågor uppmuntrar vi till ytterligare forskning. På så sätt är vårt tillvägagångssätt ortogonalt och ett komplement till Wilhelm et al. som ger en grundlig kartläggning av WCET-analysmetoder och verktyg som har utvecklats och använts inom akademi och industri. Nyckelord Värsta-fallet utförande tid (WCET) analys · Annotering språk · Path-orienterat, begränsning-orienterat, och hierarki-orienterat WCET annotation språk · WCET annotation språk utmaning Computing den tid som genomförandet av ett program kan ta i värsta fall är utmanande. Det krävs för att hantera analysproblem som är beräkningsbart svårhanterliga eller obeslutbara. Verktyg och metoder för analys av tiden i värsta fall (WCET) nöjer sig därför vanligtvis med att beräkna en övre gräns för den faktiska WCET. Dessa verktygs och metoders precision, generalitet och effektivitet beror i hög grad på exakt beskrivning och identifiering av genomförbara och ogenomförbara programvägar. En programväg är möjlig, 123 412 R. Kirner et al. Om det finns ett faktiskt program utförande tar denna väg; det är ogenomförbart annars. I praktiken beräknas denna information genom helautomatiska programanalyser, där så är möjligt; den tillhandahålls manuellt av programprogrammerare i övrigt. I båda fallen kräver detta ett särskilt språk för att kunna kommentera denna information och vidarebefordra den till en efterföljande WCET-analys. Ett sådant språk kallas vanligen ett anteckningsspråk. Under de senaste två decennierna har en rad begreppsmässigt ganska olika annoteringsspråk föreslagits för att stödja behoven hos olika WCET-analysmetoder och -verktyg. I den här artikeln presenterar vi en systematisk och omfattande jämförelse av de olika tillvägagångssätten för WCET-anmärkningsspråk. Detta verkar på vårt förslag om WCET-annotationsspråkutmaningen [32] som kompletterar WCET-verktygsutmaningen [17, 22, 62] och kompletterar den nyligen genomförda undersökningen av WCET-analysmetoder och -verktyg av Wilhelm et al. Kommissionens genomförandeförordning (EU) nr 668/2014 av den 13 juni 2014 om tillämpningsföreskrifter för Europaparlamentets och rådets förordning (EU) nr 1151/2012 om kvalitetsordningar för jordbruksprodukter och livsmedel (EUT L 179, 19.6.2014, s. 1). Med fokus på kommentarsspråk för WCET-analys tar vi en annan vinkel, som Wilhelm et al. Att bidra till att karakterisera den senaste tekniken inom WCET-analysområdet. Vi anser att detta ger en ny stimulans för fortsatt forskning och utveckling om WCET-analysmetoder och verktyg i allmänhet och annotering språk i synnerhet. Det är värt att notera att det också finns noteringsspråk för modellering av realtidsegenskaper på systemnivå som svarstid, dataflöde eller jitter. Exempel på sådana systemmodellering språk är modellering och analys svit för realtidsapplikationer som kallas MAST [23] och UML Profile for Modeling and Analysis of Real-time and Embedded systems (UML-MARK) [49]. Sådana realtidsmodelleringsspråk på systemnivå ligger dock utanför räckvidden för de språk som behandlas i denna artikel, men till exempel skulle UML-MARK kunna utvidgas genom användardefinierade egenskaper till att vara värd för annotationskoncept specifikt för WCET-analys. Bidraget till denna artikel är alltså tvåfaldigt: för det första att kartlägga de annotationsspråk för WCET-analys som har varit inflytelserika och formativa för fältet. För det andra att identifiera öppna frågor för ytterligare forskning som vi anser vara avgörande för dess vidare utveckling och framsteg. I detta syfte inför vi en uppsättning kriterier som är avgörande för lämpligheten och användbarheten av ett anteckningsspråk. Detta leder oss till ett kluster av de olika annoteringsspråken och gör det möjligt för oss att undersöka och diskutera deras relativa styrkor och begränsningar. Baserat på dessa resultat föreslår vi öppna frågeställningar för ytterligare forskning mot nya, lätta att använda och uttrycksfulla annotationsspråk, som vi tror kommer att stödja vidareutveckling av metoder och verktyg för WCET-analys. I det långa loppet kan detta också ses som ett steg mot ett universellt WCET-anmärkningsspråk för ett brett spektrum av WCET-analysverktyg. Detta skulle särskilt öka interoperabiliteten för olika stödjande programanalysverktyg för WCET-analys till ömsesidig nytta. WCET-anmärkningsspråk och WCET-beräkningsmetoder är nära knutna till varandra och kan inte på ett meningsfullt sätt betraktas som helt isolerade. Vi ger därför en kort sammanfattning av de grundläggande WCET beräkningsmetoderna och de grundläggande typerna av flödesinformation som uttrycks med hjälp av annotationsspråk i Sects. 2 respektive 3. Detta kommer att skapa förutsättningar för vår utredning och jämförelse av WCET-anmärkningsspråk. Figur 1 sammanfattar de noteringsspråk som vi betraktar, grupperade med avseende på WCET-beräkningsmetoden, de WCET-analysverktyg som använder dem är baserade på. Detta illustrerar det nära sambandet mellan WCET-beräkningsmetoder och WCET-anmärkningsspråk. WCET beräkning: grundläggande metoder WCET av ett program kan beräknas för hela programmet på en gång. Vi kallar denna globala WCET beräkning. Alternativt kan WCET beräknas på ett hierarkiskt nedifrån-och-upp-sätt. Vi kallar detta scoped WCET beräkning. Vissa av WCET: s beräkningsmetoder är i sig scoped metoder, t. ex. timing schema. Men även WCET-analys som utförs inom förfarandet istället för inter-proceduralt är en form av scoped WCET beräkning. Det är värt att notera att scoped WCET beräkningsmetoder endast är kompatibla med flödesinformation som adresserar egenskaper inom samma tillämpningsområde, dvs. med flödesinformation som endast adresserar programdelar inom samma tillämpningsområde. Den grad i vilken scoped WCET beräkning används av ett konkret WCET analysverktyg är således formativ för WCET annotation språk som ska användas med detta verktyg. Tidsschemametoden är en effektiv WCET-beräkningsmetod som också är enkel att genomföra [52, 54, 59]. Tidsschemat består i huvudsak av hierarkiska WCET-beräkningsregler för varje nod i syntaxträdet som representerar elementära eller sammansatta uttalanden. Om T (A) betecknar det lokala WCET som är bundet till en nod A, beräknas det lokala WCET med den sekventiella sammansättningen A; B av två noder A och B som T (A) + T (B). analogt, den lokala WCET av ett villkorat uttalande om A sedan B annan C fi; beräknas som T (A)+max (T (B), T (C)) och den lokala WCET bundet av en slinga medan A do B od; med som mest LB iterationer beräknas som Fig. 1 Formativa WCET-anmärkningsspråk (observera: den grå linjen indikerar att WCET-beräkningsverktyget med hjälp av TAL är hybrid och har egenskaper av hierarki-orienterade tillvägagångssätt samt av oortodoxa andra). De olika språkaspekter som jämförs och diskuteras listas systematiskt i tabell 1 i bästa fall. Dess beräknings komplexitet är linjär med programmets storlek. Den skalar därför väl och kan effektivt appliceras på stora program. Effektiviteten i denna strategi kommer till priset av att det saknas stöd för global flödesinformation, dvs. flödesinformation som beskriver relationer över gränserna för individuella tidsschemaregler. Detta beror på att timingschemametoden representerar en finkornig scoped WCET-beräkningsteknik som använder de syntaktiska elementen i styrflödeskonstruktioner som omfattning. För vissa program kan detta resultera i en mycket högre WCET-överskattning jämfört med andra WCET-beräkningsmetoder. Vidare, timing schema strategi ger inte ett gränssnitt för att modellera komplexa utförande tillstånd av moderna processorer som har funktioner som rörledningar och caches. Detta tvingar i sig en hög pessimism på WCET som är bundet till sådana processorer. Colin och Puaut [10] har presenterat en förfining av tidsschemat för en mer exakt hantering av häckade slingor [10], jfr. Sekt. 6. 6 Förhandlingsdirektiv: Som visas i bild. 1, alla tillvägagångssätt som bygger på en hierarkisk annotering språk använda timing schema för WCET beräkning. Den explicita sökvägen (EPET) söker den längsta körningsvägen genom att räkna upp och jämföra varje programsökväg. Vid en första anblick verkar detta vara ett ganska naivt tillvägagångssätt, och i själva verket skalas det inte (väl) i fallet med global WCET beräkning. Detta tillvägagångssätt har dock sina fördelar när man använder scoped WCET beräkning eftersom scoping gör det möjligt att begränsa antalet banor inom varje kluster så att deras uppräkning blir möjlig. Till exempel använder vissa vägorienterade WCET-beräkningstekniker slingor som omfattning för analysen [18, 58] Statisk WCET-beräkning baserad på EPET är väl lämpad för att analysera effekterna av rörledningar. Det gör det möjligt att modellera rörledningens påverkan på en instruktionssekvens längre än bara grundläggande block, och därmed ökar precisionen för den WCET bundna. Men EPET i sig är olämpligt att ta ganska globala timing effekter i beaktande, som cache beteende. Därför måste cacheanalysen göras i ett separat steg före EPET-steget. Den separata analysen av cach och rörledning effekter, kan dock vara unsound för processorer som visar timing anomalier [34, 44]. För mätningsbaserad tidsanalys med hjälp av EPET används en scoping för att definiera längden på de vägar för vilka timingen erhålls genom utförande-tidsmätningar. Observera att mätningsbaserad timinganalys är en hybridmetod som använder utförandetidsmätningar såväl som programanalys. Den scoping som används i mätbaserad timing analys kan vara av helt olika granularitet. Till exempel pWCET-verktyget för Bernat et al. [4] använder relativt finkornig scoping, ner till basblocksnivån. Däremot är MTime-verktygets filosofi att använda en relativt grovkornig scoping för att minska mätfelet [67]. MTime letar efter en avvägning mellan den maximala kodlängd som täcks av delvägar och antalet delvägar som ska mätas. Som visas i bild. 1, alla metoder som bygger på en väg-orienterad annotering språk använda EPET för WCET beräkning. Den implicita väguppräkningstekniken (IPET) har banats väg av Li och Malik [42], liksom av Puschner och Schedl [55]. I motsats till den sökvägsbaserade WCET-beräkningen där sökvägar uttryckligen räknas upp utför IPET en implicit längsta sökväg. Grundidén är att modellera styrflödet av programmet med begränsningar. För att minska komplexiteten används vanligtvis endast linjära begränsningar, dvs. programmet representeras som ett heltal linjärt program (ILP). Efter denna grundläggande modellering inkluderas ofta kompletterande flödesinformation på ett smidigt sätt i form av ytterligare begränsningar av ILP-problemet. Det slutligen formulerade ILP-problemet överförs till en ILP-lösare som beräknar den önskade WCET-bindningen. På grund av den breda tillgången på kommersiella och öppna ILP-lösare kan sådana ILP-problem lösas på ett bekvämt sätt. Eftersom IPET-metoden kräver att man löser en uppsättning begränsningar som beskriver programmets beteende, är det i sig en global WCET-beräkningsmetod. Det är också möjligt att använda IPET som en omfattande WCET- beräkningsteknik, t. ex. gjort av Ermedahl et al. [14].................................................................. Den IPET-baserade WCET-beräkningen är för närvarande den mest populära WCET-beräkningstekniken. Det gör det möjligt att direkt använda ganska flexibel flödesinformation som linjära flödesbegränsningar. Linjära flödesbegränsningar stöds av så många anteckningsspråk så att vi beskriver dem mer i detalj i Sect. 4. Vad är det som händer? Som visas i bild. 1, alla metoder som bygger på en begränsningsorienterad annotering språk använder IPET för WCET beräkning. Hierarki, väg- och restriktionsorienterade WCET-beräkningsmetoder används för närvarande oftast av WCET-analysverktyg. Det finns dock ytterligare metoder som använder olika metoder. Till exempel använder WCET-analysmetoden med TAL-annotationsspråket timingsschemat i kombination med fritt programmerbara algoritmer. Det är alltså inte ett rent hierarkiskt tillvägagångssätt, utan en hybrid. I Sect. 8 Vi betraktar metoder som faller i denna grupp tillsammans med deras annotering språk mer i detalj. Vi fortsätter nu med att påminna om de grundläggande typerna av flödesinformation. Flödesinformation beskriver aspekter av det dynamiska programbeteende som är relevanta för WCET-beräkning. Det uttrycks med hjälp av WCET-anmärkningsspråk. I det följande sammanfattar vi de grundläggande typerna av flödesinformation, som särskiljer statisk och dynamisk information. Det abstrakta syntaxträdet (AST) är en kortfattad återgivning av ett program som tas bort från information som är onödig för dess sammanställning [2]. I första hand beskriver AST programmets syntaktiska struktur. Oförklarligt beskriver den också sitt kontrollflöde. Kontrollflödesgrafen (CFG) är en uttrycklig representation av ett programs kontrollflöde [19]. Eftersom förgreningsbegränsningar som följs av faktiska programutföranden inte beaktas, beskriver den det statiska kontrollflödet. Noderna av CFG representerar uttalanden av programmet, och kanterna betecknar var utförandet kan fortsätta efter att ha utfört ett uttalande. Uttalanden kan kombineras till grundläggande block. En grundläggande block är en sekvens av maximal längd på uttalanden som endast kan skrivas in vid den allra första uttalande och vänster efter den sista. En CFG kan antas ha en unik startnod som representerar det allra första uttalandet och en slutnod som representerar det sista uttalandet. Det statiska styrflödet ges sedan av den uppsättning stigar som leder från startnoden till slutnoden. Program med funktioner eller procedurer representeras av ett flödesdiagramsystem, där varje Bortom loopgränser 415 funktion och procedur representeras av en vanlig CFG. En interprocedural kontrollflödesgraf eller super kontrollflödesgraf representerar kontrollflödet genom funktionsanrop och returer explicit genom att dela varje anropsplats i en ny anrops- och returnod, och införa ett anrop och en returkant som förbinder anropsnoden med startnoden för den anropade proceduren eller funktionen och dess slutnod med returnoden för motsvarande anropsplats [47]. På så sätt slås CFG:erna i flödesdiagramsystemet samman till en enda graf. Uppsättningen av sökvägar i den interprocedurala kontrollflödesgrafen från startnoden till slutnoden för programmet som respekterar anrops-/återgångsbeteendet av procedur- och funktionssamtal (även känd som interproceduralt giltiga sökvägar [60] ) betecknar det statiska kontrollflödet av ett program med procedurer och funktioner. Som för AST, alla grenar är icke-deterministiskt tolkas i en CFG och dess interprocedural förlängningar för att undvika obeslutsamhet frågor. Därför beskriver det statiska styrflödet av ett program en superuppsättning av programvägarna, för vilka det finns ett faktiskt programutförande, d.v.s., det beskriver en superuppsättning av uppsättningen genomförbara programvägar [5]. En annan representation som ofta används för att beskriva det kontrollflöde som induceras av procedur och funktion samtal är anropsdiagram över ett program [47]. En anropsgraf innehåller en nod för varje procedur och funktion av ett program. En riktad kant leder från nod m till nod n i anropsgrafen, om proceduren eller funktionen som representeras av m innehåller ett anrop för proceduren eller funktionen som representeras av n. Anropsgrafen tillsammans med flödesgrafsystemet i ett program kan också användas för att beskriva dess statiska styrflöde. Det dynamiska styrflödet begränsar det statiska styrflödet mot en mer exakt approximation av uppsättningen genomförbara programvägar. Vanligtvis uppnås detta med hjälp av en kontrollflödesanalys, som konceptuellt kan tänkas identifiera en delmängd av uppsättningen ogenomförbara programvägar. Noggrannheten i approximationen beror alltså på förmågan hos styrflödesanalysen att identifiera ogenomförbara programvägar. I detta syfte kan styrflödesanalysen styras av flödesinformation för att förbättra dess kapacitet, där flödesinformationen begränsar och begränsar det statiska styrflödet. Detta flöde information är vad som vanligtvis tillhandahålls i termer av annoteringar av programmet. Viktigast är här tillhandahållandet av övre gränser för cykler i den statiska kontrollflödet representation av ett program, som beror på slingor och (ömsesidigt) rekursiva procedur och funktion samtal. Generellt skiljer vi mellan följande typer av dynamisk kontrollflödesinformation: Loopgränser Loopgränser är den minsta information som krävs av WCET-analysatorer för att komma med en WCET som är bunden till ett program. För naturliga loopar, dvs. loopar med ett distinkt loophuvud som dominerar alla noder i loopkroppen och en bakkant som pekar mot loophuvudet [2] anger loopgränser den maximala iterationen av loopkroppen i förhållande till loophuvudet. För icke-naturliga slingor, t. ex. för obrukbara slingor, är specifikationen av slingor mindre intuitiv eftersom det inte finns någon unik slingapost. Recursion gränser Recursion gränser är liknande i smaken till loop gränser. De ger en övre gräns för antalet gånger en rekursiv funktion eller förfarande kallar sig på varje anrop. Att ange gränser för ömsesidigt rekursiva procedursamtal är mindre uppenbart och inte direkt möjligt. Inhägnade slingor med icke-rektangular iterationsutrymme Om räckvidden för en iterationsvariabel (i, j, k,...) i en inre slinga beror på det aktuella värdet av iterationsvariabeln i en yttre slinga, blir formen på iterationsutrymmet icke-rektangulär [47]. Vanliga exempel är trapetsoidal och triangulär iteration utrymmen, de senare kallas också triangeln slingor. Call contexts Call-contexts ger information om sammanhanget, i vilket ett förfarande kallas på en viss call site, t.ex. värden för procedurargument och globala variabler. Anropssammanhang gör det möjligt att analysera ett förfarande anrop webbplats specifikt. I allmänhet möjliggör detta mer exakta analysresultat. Till exempel, beräkningen av loop gränser som beror på värdena för indataparametrar eller globala variabler vid en samtalsplats, kommer vanligtvis att vara mer exakt om analysen kan hänvisa till samtal-context information på anropsplatser [38]. Loop-kontexter Loop-kontexter liknar call-kontexter men fokuserar på loopar istället för call-webbplatser. Ofta beter sig den första och följande loopen annorlunda, t. ex. på grund av cacheeffekter. Precisionen för att analysera sådana slingor kan förbättras när t. ex. ett anteckningsspråk gör det möjligt att annotera de första och efterföljande iterationer av en slinga separat. Application contexts Application contexts ger information om sammanhanget en ansökan utförs i t.ex. möjliga miljötillstånd. En applikationskontext beskriver programmets miljö, medan en utlysningskontext beskriver den lokala kontexten för en viss utlysningsplats. Naturligtvis kan en ändring i ansökans sammanhang också orsaka en ändring av ett visst ansökningsomgångssammanhang. Ett program beter sig ofta betydligt annorlunda på grund av förändringar i miljön. Analysernas precision kan därför förbättras om annoteringsspråken gör det möjligt att specificera specifika tillämpningskontexter. Execution order WCET för ett program kan vara beroende av den konkreta ordning i vilken dess uttalanden utförs, t. ex. på grund av effekterna av instruktioner pipelines, instruktioner / data caches, eller processor parallellism. De flesta WCET-beräkningsmetoder tar inte hänsyn till detta och 123 416 R. Kirner et al. nöjer sig med uppskattningar av hur ofta basblock genomförs. Om metoden däremot stöder modellering av en komplex maskinvaruarkitektur där instruktionstidpunkten beror på exekveringshistoriken, bör annotationsspråket stödja specifikationen av exekveringsordern.
Dessutom stöder toppmoderna timinganalysatorer kraftfulla annotationsspråk för att ge global väginformation REF (påverkan på WCET-optimering utvärderas i avsnitt 7.3).
Beyond loop bounds: comparing annotation languages for worst-case execution time analysis
{'venue': 'Software & Systems Modeling', 'journal': 'Software & Systems Modeling', 'mag_field_of_study': ['Computer Science']}