SE520072C2 - Metod och system för exceptionshantering - Google Patents

Description

25 30 520 072 2 människor skall kunna förmà datorer att utföra specifika uppgifter. Även om det är möjligt för människor att skapa me- ningsfulla program i maskinkod, används idag i praktiken ett eller flera av de tillgängliga programspràken vid programvaruutveckling. De mest använda programspràken är "högnivàspráken", sàsom C++/C eller Pascal.

Ett program som kallas för en "kompilator" översät- ter dessa instruktioner till erforderligt maskinspràk. I samband med denna översättning kallas programmet, som är skrivet i högnivåspràket, för "källkoden" eller käll- programmet. Det som slutligen kommer ut ur kompilatorn är en "objektmodul", vilken innefattar instruktioner för exekvering av en màlprocessor. Även om en objektmodul innefattar kod för styrning av driften av en dator, är objektmodulen i sig själv inte i en form som kan exekve- ras direkt av en dator. Istället mäste den undergå en "länknings"-process innan det slutliga exekverbara pro- grammet skapats.

Länkningen kan ses som den generella process där en eller flera kompilerade objektmoduler kombineras eller länkas tillsammans för bildande av ett exekverbart pro- gram. Denna uppgift ges vanligtvis till ett program som kallas för en "länkare". Under typisk drift tar en länka- re emot, antingen fràn användaren eller från en integre- rad kompilator, en lista med objektmoduler som önskas vara inkluderade i länkoperationen. Länkaren avsöker objektmodulerna från de objekts- och biblioteksfiler som specificerats. Efter bestämning av de sammankopplande referenserna som behövs, skapar länkaren en exekverbar avbildning genom att organisera objektkoden fràn program- modulerna i ett format som operativsystemets programlad- dare förstàr. Slutresultatet efter länkning är exekverbar kod (typiskt en .exe-fil), vilken efter testning och kvalitetssäkring överlämnas till användaren tillsammans med lämpliga installations- och användarinstruktioner 10 15 20 25 30 520 072 3 eller till en fabrik för installation i produkter med inbyggda datorsystem.

Utveckling av program är väsentligen en process av tester och felsökning. Fel som framkommer vid denna programutvecklingscykel kan delas in i breda klasser, innefattande fel vid kompilering, länkningsfel, körnings- fel och fel som uppkommer vid körning beroende på ovän- tade fel utanför programmerarens kontroll. Exempel på sådana oväntade fel innefattar fel vid externa resurser som delas via ett nätverk och fel i nätverket. Lämpliga utvecklingsmetoder och kvalitetskontroller tar bort både kompileringsfel (såsom syntax och formatöverträdelser) och länkfel (såsom biblioteks- och globala namngivnings- motstridigheter), men körningsfel är mindre medgörliga avseende systematisk eliminering. Att körningsfel är så väldigt viktiga härstammar från det faktum att de van- ligtvis upptäcks av och skapar stor irritation för slut- användaren. Om körningsfelen inte hanteras korrekt, avbryter (avslutar) dessa helt enkelt exekveringen samt lämnar systemet i ett tvivelaktigt tillstànd och lämnar användaren osäker pà vad som gick snett samt vad han skall göra sedan. Det finns många orsaker till svårig- heterna med körningsfelsproblem. För det första är det svårt att förutsäga varje användares aktivitet under en programexekvering. Fastän den samvetsgranne program- meraren guidar användaren med hjälpfulla menyer och uppmaningar samt inriktar sig på att sätta in kod som kontrollerar giltigheten hos varje svar från användaren, kvarstår i praktiken en stor programmeringsutmaning i att förutsäga och svara på godtyckliga inmatningar från användaren.

För det andra är det svårt, och ofta omöjligt, att förutsäga tillgängligheten hos olika hårdvaru- och mjukvaruresurser som krävs under programexekveringen.

Programmet som körs kan t ex begära åtkomst av RAM (Random Access Memory) och skivminnesallokeringar vid olika punkter i exekveringen, och vid avsaknad av dessa 10 l5 20 25 30 35 520 072 4 o kan inte programmet fortsätta på ett användbart sätt. Pa liknande sätt kan programmet under körning anropa opera- tivsystemrutiner, biblioteksrutiner eller andra rutiner vilka, på grund av olika orsaker som är utanför program- merarens kontroll, är otillgängliga vid detta tillfälle.

Ett vanligt fel uppkommer t ex när ett program försöker få åtkomst till en fil som inte är tillgänglig på grund av nätverksfel. Liksom med exceptioner avseende hàrdvaru- resurser måste programmet antingen agera undvikande eller helt enkelt avslutas (gås ur eller stängas ned). Excep- tioner av denna typ är särskilt vanliga i moderna pro- grammeringsmiljöer där en uppsättning av oberoende användarapplikationer eller en uppsättning av oberoende exekverande trådar inom samma program måste dela samma resurser.

Bortsett från resurstillgänglighet och oförutsägbart agerande från användaren omfattar verkliga kodningsbuggar som inte är detekterbara under kompilering eller länkning en ytterligare källa för körningsfel. Exempelvis kan ett aritmetiskt uttryck, som accepterats som tillåtet av kompilatorn, alstra ett körningsfel för särskilda värden hos dess variabla komponenter. Typiska fall är "division med noll"-fel och liknande situationer där uttrycket inte kan evalueras korrekt. Sådana fel är förutsägbara och undvikbara i teorin. I praktiken har emellertid traditio- nella exceptionshanteringslösningar omfattat ett hårdko- dat övermått av villkorliga tester av variabelvärde före evalueringen av varje uttryck, som följts av ad hoc-ruti- ner för kringgàng av ogiltiga evalueringar. Utföringsfor- men är som bäst omständig och felbenägen.

De flesta av högnivåspräken som idag används för programutveckling utnyttjar modularitetskonceptet, var- igenom en uppsättning processer som ofta begärs kan kapslas in i en särskilt namngiven subrutin, procedur eller funktion. När sådana subrutiner väl blivit kodade kan de återanvändas genom att de "anropas" från vilken punkt som helst i huvudprogrammet. Vidare kan en subrutin 10 15 20 25 30 520 072 5 anropa en subrutin, osv, varför ett exekverbart program i de flesta fall sällan är en linjär sekvens av instruktio- ner. I programmeringsspråket C skrivs t ex ett "main()"- program som anropar en sekvens av funktioner, vilka var och en kan anropa funktioner osv. Om allt går väl, åter- vänder styrningen slutligen till main(). Denna stapling av funktionsanrop förenklar konstruktionen av program, men komplicerar samtidigt hanteringen av exceptioner. Det grundläggande för ett funktionsanrop är att det måste överlämna alla argument (eller parametrar) till målfunk- tionen, överföra styrningen till minnessektionen som innehåller funktionens exekverbara kod, àterlämna resul- tatet av anropet, och samtidigt lagra tillräckligt med information för att säkerställa att efterföljande exekve- ring återupptas omedelbart efter den punkt där det ursprungliga funktionsanropet gjordes. Denna funktions- anropsmekanism, vilken är välkänd inom området, uppnås vanligtvis genom skjutning och dragning av data och minnesadresser till och från en stack före, under och efter anropet. En stack är helt enkelt en dedikerad del av minnet och är vanligtvis anordnad såsom en LIFO (sist in, först ut) datastruktur. Stacken påverkas normalt inte direkt av programmeraren, men dess innehåll förändras som ett resultat av funktionsanrop som kodats av programme- raren. Program har direkt åtkomst till en annan del av minnet, ofta benämnt extrautrymmet (heap), och ett nyckelelement i exceptionshantering omfattar hanteringen av denna viktiga resurs.

Efter ett lyckat funktionsanrop har stacken nystats av, dvs all data som skjutits till stacken har plockats bort i omvänd ordning, vilket gör att stacken efterlämnas i det tillstånd den hade före anropet och att den är redo för ytterligare funktionsanrop. Exekveringen återupptas i funktionen som gjorde anropet. Observera att, eftersom funktionsanrop kan staplas till godtyckliga nivåer, stacken måste upprätthålla en viktig, komplex sekvens av returvärde och instruktionspekare, vilka är väsentliga 10 l5 20 25 30 520 072 6 för korrekt exekvering av programmet. Slutligen, om inga problem uppstår, återgår kontrollen till main() och efter det sista framgångsrika funktionsanropet i main() avslu- tas programmet. Alla avbrott under denna avnystningspro- cess leder till en obalanserad stack och oförutsägbara resultat. Exempelvis förväntar sig en anropad funktion att finna sina argument i en särskild sektion, känd som funktionens stackram, vid stackens topp. Om stacken år obalanserad, kommer funktionen att dra av felaktig data och ytterligare bidra till körningsfelet.

Exceptionella tillstànd och fel som uppstår i en staplad funktion kan tydligen skapa ett särskilt svårt problem. Flera exceptionshanteringslösningar har provats för att lösa problemet. En lösning är t ex att låta varje funktion återsända en felindikation, antingen i en sepa- rat variabel eller såsom en speciell rad av värde för det normala återsändningsvärdet. Det omedelbara ansvaret för exceptionshantering vilar då på den anropande funktionen.

Om den anropande funktionen är oförmögen att hantera detta, måste den återsända en felindikation till sin anropande funktion, osv uppåt i kedjan till dess att antingen en funktion som kan hantera exceptionen nås eller till dess att main() nås. Om main() inte kan rätta till problemet, avslutas det så elegant som möjligt, kanske genom att presentera ett förklarande meddelande för användaren.

Låt oss, som en illustration, anta att main() anro- par funkA() funkB() är programmerad att returnera O för framgång som i sin tur anropar funkB(). Låt säga att eller ett positivt värde som indikerar felorsaken. Exem- pelvis kan funkB() returnera l för "otillräckligt minne", 2 för funkA() testar alltid det från funkB() Om detta test indikerar framgång, fortsätter funkA() och återlàmnar slutligen "filen inte funnen" osv. returnerade värdet. styrningen till main(). Om funkA() detekterar att funkB() utsattes för ett "otillräckligt minne"-fel, skulle den mycket väl kunna rätta till situationen (genom att "samla 10 l5 20 25 30 520 072 7 skräp" (collecting garbage) eller genom att defragmentera extrautrymmet (heap)) och sedan anropa funkB() igen. Men om funkA() detekterar "filen inte funnen"~felet, har den kanske inte några andra organ för hantering av denna situation än presentation av en varning. funkA(), som är oförmögen att fortsätta, måste då returnera ett felvärde till main(). Vad, om någonting, main() kan göra med detta fel beror naturligtvis på den specifika applikationen.

Förtjänsten med detta "fellänknings"-arrangemang är att stacken alltid nystas av på rätt sätt, men det har flera allvarliga nackdelar. Varje funktion i kedjan är belastad med kod som "söker" efter exceptioner som upp- står i de funktioner de anropat. Denna kod måste också bestämma vilka exceptioner som kan hanteras och vilka som måste returneras till den anropande funktionen. När många funktionsanrop är staplade på varandra och antalet olika exceptionstyper ökar, blir testningen och länkningen av exceptioner en stor, felbenägen programmeringssvårighet.

Ett väsentligt hinder avseende välformulerad, lättläst, lättunderhällen kod syns i det enkla exempel som beskri- vits ovan. Om main() skall hantera en exception som returnerats av funkA(), kan den behöva veta både excep- tionstypen och var exceptionen uppstod. Exceptionstypen är tydlig från felkoden, men det faktum att den uppstod i funkB() och inte i funkA() eller, om programmet ändras och utökas, i någon annan funktion i kedjan, är inte omedelbart självklart utan ytterligare felkodning.

Ett svar på detta problem är den globala (eller långa) gå-till-märke-instruktionen som kan överföra styrning från vilken punkt som helst i vilken funktion eller rutin som helst som finns var som helst i minnet vid den adress som ges av identifieraren, märket. Under denna ordning behöver inte funkB() i det efterföljande exemplet returnera felkoder uppåt i funktionskedjan, utan den kan, vid detektering av ett fel, sända styrningen direkt till en lämplig exceptionshanterare. 10 15 20 25 30 520 072 8 Exempelvis antas en exceptionshanterarrutin vid inget-minne-hanteraren (no-mem-handler) hantera alla "otillräckligt minne"-fel och, om nödvändigt, använda värdet hos serr för att bestämma i vilken funktion felet uppstod. I den aktuella terminologin "kastar" funkB() "otillräckligt minne"-exceptionen, medan rutinen vid inget-minne-hanteraren "fångar" exceptionen.

Denna enkla globala gå-till-lösning har fördelen att erbjuda ett enda läsbart ställe för varje exceptionshan- terare, men i praktiken skapar den andra problem. För det första arbetar standard gå-till-instruktionen i språken C och C++ endast inom en funktion. Den saknar den önskade långdistansmöjligheten för överföring av styrningen mellan funktioner. För det andra misslyckas, som läget är, den direkta överföringen till en hanterare med att på ett riktigt sätt nysta upp stacken, såsom beskrivits tidigare. Slutligen, och i anslutning till de första två argumenten, behövs ytterligare mekanismer för att medge att styrningen returneras, om nödvändigt, till den kas- tande funktionen. För att återuppta exekveringen i den kastande funktionen vid dessa tillfällen när hanteraren är anordnad att "rätta" felet måste exceptionshanterings- mekanismen tillåta att den kastande funktionens tillstånd eller struktur bevaras och återskapas.

När funkB() lokala variabler särskilda värden. Såsom namnet antyder kastar en exception innehåller t ex dess är verksamheten och existensen av lokala variabler be- gränsad till funktionens "livstid", de försvinner när funktionen lämnar ifrån sig styrningen. Dessa lokala värden och andra parametrar såsom de aktuella värdena i den centrala processorns register utgör funkB():s till- stånd. Särskilt innefattar tillståndet stackstatusen och den aktuella IP:n (instruktionspekaren) som markerar platsen i minnet där exekveringen måste återupptas. Detta tillstånd måste sparas fullständigt innan hanteraren anropas och därefter återställas fullständigt innan exekvering av funkB()säkert kan återupptas. 10 l5 20 25 30 520 072 9 Vissa av bristerna med den globala gå-till-lösningen har lindrats genom introduktionen av två biblioteksfunk- tioner i standard C, setjmp() och longjmp(). setjmp() kan anropas i vilken funktion som helst vid punkten där styr- ningen skall återupptas om en motsvarande longjmp() an- ropas i en annan funktion. Typiskt anropas longjmp() när en exception kastas. Som argument tar setjmp() adressen av (pekare till) en av programmeraren tillhandahàllen minnesbuffert, i vilken den aktuella funktionens till- stånd kommer att sparas. Såsom beskrivits tidigare inne- håller detta tillstånd processorregisterna, innefattande den aktuella instruktionspekaren IP (även kallad program- räknare PC), som behövs för att àteruppta exekveringen Till skillnad från gå-till kan longjmp() överföra styrningen över olika omedelbart efter anropet av setjmp(). funktioner såsom följer: longjmp() tar såsom ett av sina argument samma buffertadress som används i motsvarande setjmp(). När longjmp() anropas återställer den tillstån- det som sparades av setjmp() och överför styrningen till den adress som hittas i nämnda lagrade IP, vilken är instruktionen som följer efter setjmp()-anropet. Vidare tar longjmp() ett andra numeriskt argument som kan testas i funktionen som anropade setjmp() och tillhandahåller därigenom en mekanism för bestämning av vilken specifik longjmp() som orsakade hoppet.

I funkA(), funkB() eller i vilken funktion som helst som de anropar eller i vilken funktion som helst som dessa i sin tur anropar (osv), säkerställer programsatsen "longjmp (aJmpBuf, status);" att nämnda setjmp() i funkA() kommer att "anropas igen" under särskilda omstän- digheter för att returnera värdestatus i retval, efter vilket styrningen återgår till "if(retval)"-raden i funkA(). I avsaknad av några longjmp()-anrop i efterföl- jande funktioner returnerar setjmp() noll (falsk), så att nämnda "if(retval)"-test misslyckas. Sålunda erbjuder nämnda setjmp()- och longjmp()-par en global gå-till- metod för exceptionshantering. Exceptionshanterare kan lO 15 20 25 30 520 072 lO kapslas in i vilken lämplig uppsättning av funktioner som helst och efter lämplig hantering kan styrningen, om så krävs, säkert återöverföras till funktionerna i vilka exceptionen uppstod.

Nämnda setjmp()/longjmp()-lösning har emellertid också nackdelar. För det första finns det ingen garanti för att funktionen till vilken longjmp() återvänder fort- farande är aktiv. I det föregående exemplet är det möj- ligt att fna() redan har återvänt och lämnat sin plats på stacken innan en motsvarande longjmp() påträffas. Den enda lösningen till detta problem är att begränsa setjmp()-anrop till nämnda main()-program. För det andra kräver problemet med avnystning av stacken i närvaro av staplade setjmp() och longjmp() noggrann och tydlig pro- grammering. Slutligen utnyttjar många populära program- överlagringstekniker (program overlaying techniques) och virtuella minnestekniker (virtual memory techniques) särskilda stackar, så att en funktions status inte lagras fullständigt av setjmp(). Alla av de beskrivna, idag ak- tuella lösningarna har misslyckats med att lösa problemet med hantering av exceptioner tillräckligt väl.

Lokala variablers tillstànd är till och med mer komplexa i språk såsom C++, där lokala variabler eller objekt måste ha särskilt associerade funktioner, kända såsom "destruerare" (destructors), vilka måste anropas före de försvinner.

Vissa programspråk, t ex C++ och andra högnivåspråk, har specifika mekanismer för att underlätta programme- ringen för exceptioner, vilka ersätter och utökar de tidigare nämnda strukturerna. Implementeringen av dessa mekanismer är emellertid komplicerad. Där finns problem som leder till avvägningssituationer mellan hastighet och utrymme, vilka problem är väldokumenterade i känd teknik.

Ett särskilt problem hänför sig till hur man opti- malt mappar platsen för àtergångsadressen till den an- ropande funktionen, till information som är nödvändig för avnystning av anropsfunktionsstacken till den punkt där 10 l5 20 25 30 520 072 ll en hanterare finns eller till den punkt där ett beslut avseende anrop av funktionen "terminate()" finns. Infor- mationen som màste mappas till återgångsadressen innefat- tar en pekare till en tabell som innehåller data som är nödvändig för avnystning av stackramen, vilken åter- ställer registerna, återställer stackpekaren och informa- tion avseende den generella stackramsutformningen och omfattar en beskrivning av tillåtna och uppfångade exceptioner i denna ram. Alternativt kan tabellinforma- tionen komprimeras och lagras istället för pekaren. Den optimala layouten hos en stackram är starkt beroende av funktionen som anropar den och kan inte gissas utan mer information än återgångsadressen och stackpekarens och/eller rampekarens värde såsom är applicerbart för en särskild implementering. Det är önskvärt att implemente- ringar av exceptionshanterare ger så litet extrainforma- tion (overhead) som möjligt när exceptioner inte kastas, eftersom de endast är avsedda att användas undantagsvis.

Den dominerande implementeringen i känd teknik hänför sig till programräknarbaserade tabeller. Tiden det tar att söka i tabellen med programräknarområden genom användning av ett aktuellt värde på ätergàngsadressen är emellertid relaterat till programmets storlek. Om en binär sökning används, vilket typiskt används, är sök- tiden logaritmisk och baserad på antalet anrop i ett program. Självklart kan denna sökningsteknik optimeras genom användning av hash-funktioner och liknande, vilka är kända. Emellertid använder inga kända implementeringar hash-funktionslösningen, troligtvis på grund av att den skulle introducera ett extra länksteg och att många pro- grammerare inte anser att söktiden är viktig.

En alternativ implementering baseras på att infor- mation tillhandahålls för lokalisering av informationen genom att den lagras på platser som är adresserade i koden som anropar exceptionen nära ätergàngsadressen. Den kända teknikens tekniker kräver emellertid programutrymme eller extra operationer för processorn för att hoppa över 10 15 20 25 30 LU LH 520 072 12 extrainformationen i anropskoden vid användning av kon- ventionella anropstekniker. Exempelvis skulle överhopp- ningen kunna vara implementerad vid återgången, medelst vilken instruktion som helst som inte har någon synlig effekt på dataflödet, såsom en "no operation NOP" med ett oanvänt data- eller adressfält som kostar programutrymme, eller en flytta-instruktion som flyttar annars oanvänd data, i vilken det oanvända fältet eller datan innehåller den önskade informationen för exceptionshanteraren och kostar programutrymme samt extrainformation för proces- sorn. Se Chase, Implementation of Exception Handling, Part 1. The Journal of C Language Translation (ISSN 1042- 5721), volym 5, nummer 4 juni 1994 (andra avsnittet i volym 6, nummer 1, september 1994).

Sammanfattning av uppfinningen Enligt föreliggande uppfinning läggs nämnda kontext- data i kod-område (in-code contextdata) in i en speciell anropsinstruktion, vilken känns igen av processorn.

Informationen hoppas över vid tiden för funktionsanropet och läses vid tiden för stackavnystningen. Denna spe- ciella anropsinstruktion kan vara implementerad för körning utan någon kostnad för extracykler i jämförelse med normala instruktioner, med undantag för externa exekveringstidsberoenden avseende sådana anordningar såsom ett cacheminne som är inblandat i instruktions- hämtningen, eftersom det under normal exekvering aldrig borde vara nödvändigt att verkligen ha åtkomst till informationen. Åtkomst till informationen sker endast under exceptionshantering.

Mängden överhoppad information år företrädesvis fast, och innehåller tillräckligt mycket data för att omfatta en pekare till information för den specifika stack-layouten, information om lokala test-block (local try blocks) och upprensningsinformation, eller tillräck- ligt för att innehålla en pekare och komprimerad kontext- data. Den verkliga kontext-datan kan komprimeras medelst konventioner såsom att adresser aldrig är udda eller 10 15 20 25 30 h.) UT 520 072 13 negativa, så att informationen i kod-område innefattar verklig data som behövs för avnystning av stacken.

Sålunda kan den överhoppade informationen ses som ett fält i instruktionen som gör att exceptionen kastas.

Alternativt kan överhoppningen ses som en sidoeffekt av instruktionen.

Följaktligen åstadkommer föreliggande uppfinning en ny mikroprocessor eller ett annat databearbetningssystem med ett nytt kommando häri märkt JSRC, vilket står för hoppa-till-subrutin-med-kontext-data (jump to subroutine with context data). Det nya kommandot har alla särdrag som finns hos de traditionella hoppa-till-subrutin- kommandona plus ett extra långt ord som innehåller en adress till kontext-tabellen, verklig kontextdata eller en kombination av båda. Kontext-information används för att hålla reda på vilken del av en given funktionskod som exekveras när exceptionen kastas. När funktionen exekve- ras och en exception uppstår vid någon slumpmässig punkt gör kontext-tabellen det möjligt för systemet att bestäm- ma vilken upprensning som år nödvändig innan stackramen kan kastas iväg och huruvida det finns några test-block som är aktiva under exceptionen. För en given funktion skapas en kontext-tabell som beskriver den effektiva layouten hos funktionen som används för dessa processer.

Denna kontext-data produceras av kompilatorn, vilken kompilerar funktionsanrop inpackade i ett test-block med en ny instruktion som innehåller kontext-data i kod- område såsom beskrivits ovan. Denna instruktion kan förstås genom att den jämförs med standard JSR-instruk- tionen, vilken inte innefattar nämnda kontext-data i kod- område som beskrivs mer detaljerat nedan.

En stackavnystare i exceptionshanteraren nystar av stacken på ett sätt som år identiskt med den kända tekni- ken, med det undantaget att den snabbare kan lokalisera kontext-tabeller för varje funktion som tagits bort från stacken under avnystning, eftersom det inte föreligger något behov av sökning i kontext-register efter en mot- lO 15 20 25 30 35 520 072 14 svarighet. Snarare används JSRC-instruktionens kontext- data för hoppning direkt till det korrekta kontext- posten.

Sålunda kan föreliggande uppfinning karaktäriseras såsom ett databehandlingssystem som svarar på instruk- tioner i en uppsättning instruktioner för exekvering av en process. Systemet innefattar instruktionshämtnings- logik som hämtar instruktioner i en uppsättning av instruktioner för tillhandahållande av en instruktions- sekvens som svar pà en instruktionspekare eller en programräknare. Instruktionsuppsättningen innefattar en kontext-anropsinstruktion (t ex JSRC) som är av normal längd och som följs av kontext-data i kod-område av en bestämmande längd som utnyttjas vid exekvering av en exceptionshanterare, vilken svarar på kontext- anropsinstruktionen. Instruktionsavkodningslogik är kopplad till instruktionshämtningslogiken och avkodar en aktuell instruktion i sekvensen som exekveras.

Instruktionsavkodningslogiken innefattar logik för detektering av kontext-anropsinstruktionen_ Exekveringsresurser är kopplade till instruktions- avkodningslogiken som exekverar de avkodade instruk- tionerna. Logik är kopplad till instruktionshämtnings- logiken som uppdaterar instruktionspekaren som svar på detekteringen av kontext-anropsinstruktionen medelst instruktionsavkodningslogiken. Som svar på detekteringen hoppar instruktionspekaren över nämnda kontext-data i kod-område till en annan instruktion i sekvensen, så att nämnda data i kod-område inte påverkar den normala behandlingen av instruktionen.

Enligt en annan aspekt av uppfinningen innefattar systemet ett programminne som är kopplat till instruk- tionshämtningslogiken och i vilken instruktioner i instruktionsuppsättningen lagras på platser som är åt- komliga som svar på instruktionspekaren. Nämnda kontext-- data i kod-område lagras efter kontext- anropsinstruktionen med en förskjutning på noll eller 10 15 20 25 30 520 072 l5 flera byte och logiken som uppdaterar instruktionspekaren hoppar över ett datafält vid förskjutningen med en längd som är lika med den bestämmande längden.

Såsom nämnts ovan innefattar instruktionssekvensen en eller flera funktioner som karaktäriseras av avnyst- ningsinformation och layoutinformation som används för att nysta av nämnda en eller flera funktioner för behand- ling av kontext-anropsinstruktionen. Nämnda kontext-data i kod-område innefattar åtminstone en delmängd av den oavnystade informationen och/eller en delmängd av layout- informationen. I ett alternativt system innefattar nämnda kontext-data i kod-område en pekare till en minnesplats där information avseende en kontext lagras för användning av kontext-anropsinstruktionen. I en alternativ utföringsform innefattar nämnda kontext-data i kod-område ett flertal databyte och omfattar ett fält för specificering av ett format för nämnda flertal byte.

Sålunda indikerar t ex fältet huruvida nämnda flertal byte innefattar omedelbar kontext-data och huruvida nämnda flertal byte innefattar en pekare till kontext- data i en annan minnesposition.

Enligt andra aspekter av uppfinningen är den bestämmande längden hos kontext-data i kod-område förutbestämd, så att instruktionsavkodningslogiken automatiskt kan uppgradera programräknaren utan ytterligare behandling. I andra utföringsformer kan den bestämmande längd hos kontext-data i kod-område bestämmas vid instruktionsavkodningstidpunkten.

Föreliggande uppfinning kan också karaktäriseras som en metod för behandling av instruktioner i databehand- lingssystemet, vilken behandling innefattar lagring av instruktioner från en uppsättning av instruktioner i det adresserbara minnet. Uppsättningen av instruktioner inne- fattar en kontext-anropsinstruktion såsom beskrivits ovan. Metoden innefattar hämtning av en sekvens av inst- ruktioner från minnet som svar på en instruktionspekare, vilken identifierar en adress i det adresserbara minnet. lO 15 20 25 30 35 520 072 16 Därefter avkodas en aktuell instruktion, vilket innefat- tar detektering av kontext-anropsinstruktionen_ Instruk- tionspekaren uppdateras med kontext-anropsinstruktionens normala längd plus kontext-datans bestämmande längd som svar på detekteringen av kontext-anropsinstruktionen, annars uppdateras instruktionspekaren med den aktuella instruktionens längd, vilken instruktion innefattar vilka operander som helst om det är lämpligt. Därefter exekve- ras kontext-anropsinstruktionen för anropning av en funk- tion såsom en normal anropsinstruktion skulle göra. Den anropade funktionen återgår normalt på samma sätt som vid en normal anropsinstruktion. Emellertid, om den anropade funktionen inte återgår normalt, utan en exception istäl- let kastas, vilken i sin tur inte råkar bli hanterad förrän när stackavnystningen når punkten för detta anrop, kommer stackavnystaren att läsa nämnda kontext-data i kod-område vid en adress i det adresserbara minnet som bestäms som svar på en funktion av instruktionspekaren.

Nämnda kontext-data i kod-område innehåller då information som är nödvändig för finnandet av någon lokal exceptionshanterare, stacklayout och upprensningsinforma- tion.

Därav följer att föreliggande uppfinning tillhanda- håller ett datorsystem för exekvering av program. Sys- temet innefattar en mikroprocessor och minne, vilket innefattar ett stackminne för lagring av funktionsargu- ment och lokal data. En uppsättning av instruktioner i mikroprocessorn och exekverbara av mikroprocessorn åstad- kommer dataflöde och styrflöde som är nödvändiga för exekvering av en representation av ett program som använ- der språket som definierats av uppsättningen av instruk- tioner. En eller flera av instruktionerna består av en kontext-anropsinstruktion. Den särskilda funktionsanrops- instruktionen är kopplad till ett datafält för bärande av kontext-data i kod-område vid en fast punkt relativt den uppfattade återgàngsadressen för funktionsanropet, eller andra adresseringssidoeffekter i den speciella anrops- 10 15 20 25 30 35 520 072 17 funktionsinstruktionen som har denna effekt. Datafältet är tillräckligt stort för att innehålla information avseende layouten av funktionsargumenten, lokala data och information som är nödvändig för avnystning av funktionen vid behandling av synkron eller asynkron exceptionsinfor- mation i en utföringsform. Alternativt är datafältet tillräckligt stort för att innehålla information som är nödvändig för att ta fram platsen där det finns informa- tion avseende layouten för funktionsargument, lokala data och information nödvändig för avnystning av funktionen och behandling av synkron eller asynkron exceptionsinfor- mation. Datafältet behandlas av mikroprocessorn på ett sådant sätt att den specifika namngivna funktionsanrops- instruktionen inte adderas till exekveringstiden. En föredragen utföringsform är en variant av JSR-instruk- tionen i CRIS-arkitekturen fràn AXIS Communications AB som beskrivs i "AXIS ETRAX: CRIS Programmers Reference", 1994 àrs utgàva, tillgänglig från "Technical Publica- tions, Axis Communications, Scheelevägen 16, S-223 70 Lund, Sweden" eller fràn , vilken införlivas som referens som om den skulle varit fullt beskriven häri.

Andra aspekter av och fördelar med föreliggande uppfinning kan ses vid granskning av figurerna, den detaljerade beskrivningen och kraven som följer.

Kort beskrivning av ritningarna Fig l är ett förenklat blockschema över ett data- system som innefattar en processor för exekvering av kontext-anropsinstruktionen enligt föreliggande uppfin- ning.

Fig 2 visar en mjukvaruarkitektur för ett utveck- lingssystem som skall exekveras av datorsystemet i fig l eller andra datorsystem som kompilerar mjukvara som inne- fattar resurser för JSRC-instruktionen enligt föreliggan- de uppfinning. 10 15 20 25 30 35 520 072 18 Fig 3 visar layouten hos nämnda JSRC-instruktion med avseende pà särskilda utföringsformer i jämförelse med en normal anropsinstruktion.

Fig 4 är ett förenklat blockschema över en mikropro- cessor enligt föreliggande uppfinning innefattande resur- ser för hantering av JSRC-instruktionen enligt förelig- gande uppfinning.

Fig 5 är ett förenklat blockschema över program- räknaruppdateringslogiken enligt föreliggande uppfinning.

Fig 6 används för att beskriva behandlingen av JSRC- instruktionen i en mikroprocessor enligt föreliggande uppfinning i jämförelse med en normal anropsinstruktion.

Fig 7 visar stacktillväxt samt kontext-data och används för att förklara föreliggande uppfinning.

Fig 8 visar ett flödesschema över ett exempel pà en exceptionshanterare enligt föreliggande uppfinning.

Beskrivning av föredragna utföringsformer A. Systemhàrdvara Föreliggande uppfinning kan utföras pä ett datorsys- tem sàsom systemet 20 i fig l, vilket innefattar en central processor 22, ett huvudminne 24 och periferi- anordningar 26, vilka t ex innefattar en in/ut-styrenhet, ett tangentbord, en pekanordning (t ex mus, styrkula (track ball), penanordning eller liknande), en presenta- tionsenhet och en masslagringsenhet (t ex en härddisk).

Systemet 20 kan förses med ytterligare in/utanordningar, såsom en skrivaranordning, om sà önskas. De olika system- komponenterna kommunicerar via en systembuss eller liknande arkitektur.

B. Systemmjukvara Följande beskrivning kommer att fokuseras pà de aktuella föredragna utföringsformerna av föreliggande uppfinning, vilka fördelaktigt kan användas på en mängd plattformar och i en mängd miljöer, oavsett om de är kommandoradbaserade eller GUI-baserade, innefattande MS- DOS, Macintosh, UNIX, NextStep, Microsoft Windows och liknande. Därför är följande beskrivning av exemplifie- 10 15 20 25 30 35 520 072 19 rande utföringsformer avsedda att illustrera, inte begränsa.

Sàsom visas i fig 1 tillhandahålls exekverbara program 32 för styrning av datorsystemets funktion.

Programmen, som är lagrade i systemminnet 24 och på skivminnet, innefattar en kernel eller ett operativsystem (OS) (Windows shell) gränssnitt. Vid vissa inbyggda system tillhandahålls och typiskt ett fönster-skal eller inget användargränssnitt. Ett eller flera applikations- program, såsom applikationsprogram eller fönsterapplika- tionsprogram, kan "laddas" (dvs överföras fràn en lag- ringsplats till minnet) för exekvering av systemet.

Programmen 32 innefattar även ett utvecklingssystem 150 enligt föreliggande uppfinning för utveckling av system och applikationsprogram. Såsom visas innefattar utveck- lingssystemet 150 komponenter som växelverkar med systemet genom fönsterskalet, liksom komponenter som växelverkar direkt genom OS.

Utvecklingssystemet 150 innefattar i detta exempel Borland C++ (registrerat varumärke), som är tillgängligt fràn Borland International i Scotts Valley, Kalifornien.

Applikationsmjukvara kan à andra sidan vara vilken som helst av en mängd applikationsmjukvaror, innefattande ordbehandlingsprogram, databasprogram, kalkylprogram, textredigerare, styrapplikationer, nätverksanordnings- drivsrutinsmjukvara och andra användarapplikationer och inbyggda applikationer.

Nämnda CPU 22 innefattar logik 149 och utvecklings- systemet 150 innefattar komponenter, vilken logik och vilka komponenter stöder nämnda särskilda JSRC-instruk- tion för hantering av exceptioner enligt föreliggande uppfinning.

C. Utvecklingssystem Utvecklingssystemet 150 enligt föreliggande uppfin- ning, vilket visas mer detaljerat i fig 2, innefattar en kompilator 153 och en länkare 180. Genom ett gränssnitt tillhandahåller utvecklingsanvändaren källmoduler 161 l0 15 20 25 30 35 520 072 20 till kompilatorn 153. Gränssnittet innefattar både kom- mandoradsdrivna gränssnitt och gränssnitt för integrerad (IDE, ment), varvid den första accepterar mottagning av använ- utvecklingsmiljö Integrated Development Environ- darkommando genom kommandoradsparametrar och den senare tillhandahåller menybaserade ekvivalenter därav. Från källkodslistningarna 161 och från listrubriks/till- behörsfilerna 151 kompilerar eller genererar kompilatorn 153 objektmoduler 163. särskilda JSRC-instruktionen på lämpliga platser i koden Kompilatorn 153 sätter in den och bestämmer den därtill hörande kontext-datan. Beroende pà kontext-datans format formuleras kod-områdesdelen av kontext-datan och placeras i objektmodulerna i ett fält med förutbestämd längd efter själva JSRC-instruktionen.

Resten av kontext-datan placeras i en tabell tillsammans med annan kontext-data som är kopplad till programmet som skall exekveras och en pekare till den plats i tabellen där resten av kontext-datan finns sätts in i nämnda kontext-data i kod-område. I alternativa system kan kontext-datan för ett givet anrop komprimeras och sättas in fullständigt i nämnda kontext-datafält i kod-område.

Därefter länkar eller kombinerar länkaren 180 objektmodulerna 163 med biblioteken 171 för generering av exekverbara program 165 (motsvarar block 32 i fig 1), vilka kan exekveras av en màlprocessor (t ex processor 22 i fig 1). Standardbiblioteken 171 innefattar tidigare kompilerade standardrutiner såsom grafik, I/O-rutiner, uppstartskod och liknande. En avbuggare 181 till- handahålls för hantering av körningsfel i programmen 165 i enlighet med föreliggande uppfinnings JSRC-teknik. En beskrivning av den generella funktionen hos ett känt, representativt utvecklingssystem 150 finns i Borland C++ (registrerat varumärke), vilket är tillgängligt direkt från Borland International.

En avbuggare 181 kan tillhandahållas för att fånga körningsfel och/eller exceptioner som kastas från pro- grammen 165 eller biblioteken 171. Avbuggaren kan ingripa 10 15 20 25 30 520 072 21 i aktiviteter från en exceptionshanterarmodul som kan komma från biblioteken 171 eller kan uttryckas som av kompilatorn 153 internt utgiven kod 165. Exceptions- hanteringsmodulen (exceptionshanteraren) som anropas från koden som givits ut av kompilatorn 153 när en exception kastats hanterar avnystning av stacken, upprensning av lokala objekt, lokalisering och exekvering av exceptions- hanterare. Exceptionshanteringsmodulen är en del av den exekverbara koden 165. Exceptionshanteringsmodulen använ- der nämnda kontext-data i enlighet med föreliggande uppfinnings JSRC-teknik.

Exceptionshanterarna i det exekverbara programmet 165 är liksom avbuggningsmodulen 181 försedda med resur- ser för åtkomst av nämnda kontext-data i kod-område som svar på kastandet och uppfángandet av en exception.

Platsen för nämnda kontext-data i kod-område för en kastad exception kan bestämmas medelst en funktion av värdet i mikroprocessorns programräknare såsom beskrivs mer detaljerat nedan. I en föredragen utföringsform där nämnda kontext-data i kod-område förskjuts med noll byte från slutet av nämnda JSRC-instruktion och dess operander, som normalt är närvarande i JSR-instruktionen och har en förutbestämd längd på t ex 4 byte, är platsen för nämnda kontext-data i kod-område helt enkelt programräknaren minus 4 byte. En förklaring av styrningen av programräknaren tillhandahålls nedan.

En detaljerad bakgrund avseende problemet med att lokalisera exceptionshantering i den kända tekniken kan bl a hittas i det amerikanska patentet 5 628 016.

Fig 3 visar implementeringen av nämnda hoppa-till- subrutin med kontext-datainstruktion i kod-område JSRC (jump to sub routine with in-code context data instruction) enligt föreliggande uppfinning i jämförelse med standard JSR-instruktionen på assemblerkods- och binärkodsnivåer.

På den första raden 301 visas assemblerkodsmärk- ningen för JSR-instruktionen, vilken bär etiketten lO l5 20 25 30 35 520 072 22 "A_function" som en operand. Operanden "A_function" representeras av det hexadecimala värdet Oxl35ef382. Den andra raden 302 visar det binära värdet som skall lagras i en exekverbar fil, med den minst signifikanta byten (82) först. Den tredje raden 303 visar JSRC-instruktio- nens layout i enlighet med föreliggande uppfinning, vil- ken instruktion bär adressen till funktionen "A_function" och nämnda kontext i kod-område såsom adressen till kontext-tabellen märkt "This_context_table" som parametrar. Det binära värdet för denna instruktion visas pá rad 303. Adressen till denna kontext-tabell represen- teras hexadecimalt av Ox5577aacc.

En alternativ utföringsform av instruktionen bär en hänvisning till ett register snarare än en parameter som ett argument i JSR- och JSRC-instruktionerna. Sålunda illustreras pà rad 305 standard JSR-instruktionen bärande registeradressen R5 som argument. I denna utföringsform av JSR-instruktionen bärs hänvisningen till register R5 i den minst signifikanta byten i instruktionen. Den binära representationen av detta illustreras pà rad 306. På rad 307 visas JSRC-instruktionen enligt föreliggande uppfin- ning, vilken bär registeradressen R5 som ett argument.

Den binära representationen visas pà rad 308.

I detta exempel är JSR-instruktionens hexadecimala standardrepresentation 0xbd3f och JSRC-instruktionens hexadecimala standardrepresentation 0x3d3f.

I en utföringsform som bär komprimerad kontext-data kan fältet bestämmas i enlighet med följande exempel. Här antar vi att det finns sju register som används för gene- rella ändamàl och är namngivna RO upp till R6. Antag att kontext-informationen som vi behöver för denna anrops- punkt innefattar stacklayout, test-blocks-kontext, lokala objekt som behöver destrueras och exceptionshanterare även kända som fàngstblock.

Antag att det vanliga fallet är att det inte finns nägra objekt som är i behov av att destruerare anropas, att det inte finns några "öppna" test-block eller fängst- 10 15 20 25 30 35 520 072 23 block för denna anropspunkt, varför användning av det komprimerade formatet pekar mot att dessa listor är tomma.

Antag även att stackpekaren används som bas för denna kontext.

Dessa 31 bitar behöver nu bara koda stacklayouten, vilken för den föredragna utföringsformen skulle vara: 0 Förskjutningen till anroparens àtergàngsadress. 0 Vilka register som är sparade. 0 Stackmängd som är allokerad för lokala variabler.

Antag att det normala fallet är att stackramen inte är större än 16 Kbyte, sä vi tar 14 bitar till förskjut- ningen till anroparens ätergàngsadress. Lokala variabler kan då också uppta 16 Kbyte, vilket är ytterligare 14 bitar. Antalet sparade register är oftast mindre än 7 (ofta fortlöpande fràn rO och upp, stoppande vid r6), varför vi endast behöver 3 bitar (noll = inga register) för detta. bit #: Betydelse: 0 Kontexten är i komprimerad form = 1, pekare till tabell = O.

Under antagande att bit 0 är 1: 1..14 Förskjutning för anropares sparade PC (àtergàngsadressen) l5..28 Mängd av lokala variabler, räknade i byte (justeringen som behövs till stackpeka- ren). 29..31 Kodad information på sparade register: ingen, rO, rO .r1, ..., rO...r6 Det andra fältet kan härledas fràn det första och det tredje fältet, varför mer information kan fås in här, kanske någonting frän den tidigare antagna tomma listan.

Exempelvis kan kanske 15 bitar användas som en förskjut- ning fràn denna plats i koden till en förenklad tabell. 10 15 20 25 30 520 072 24 Detta komprimerade format betyder då att vi inte ger ut någon tabell med denna information för de flesta av anropskontexterna och pà sä sätt kan vi spara mycket minne.

Kompilatorn sätter sålunda in JSR-koden pà lämpliga ställen i objektmodulerna som kompilerats, om kontext-- datan i kod-område inte är lämplig i det särskilda fallet. I de fall där JSRC-kontext-data i kod-område är lämplig, sätter kompilatorn in JSRC-instruktionen i den form som illustrerats.

Vid exekvering av instruktionen svarar programräk- naren och instruktionshämtningslogiken, som är associerad med processorn som använder denna teknik, på detekte- ringar av en JSRC~instruktion för ökning av programräkna- ren, eller någon annan ekvivalent instruktionspekare, runt den kontext-data i kod-område som inte behöver läsas vid normal behandling. Fig 4 och 5 illustrerar sålunda strukturen hos en mikroprocessor som är konfigurerad att exekvera JSRC-instruktionen och logiken för ökning av programräknaren i kontexten av en JSRC-instruktion enligt föreliggande uppfinning. Fig 4 är sålunda ett förenklat schema över en processor eller CPU som är implementerad enligt föreliggande uppfinning. Den innefattar ett fler- tal funktionella enheter 400. De funktionella enheterna 400 omfattar exekveringsenheter för aritmetiska och logiska funktioner, instruktionsavkodningslogik, vilken innefattar logik som detekterar och avkodar JSRC-instruk- tioner enligt föreliggande uppfinning, programräknarupp- dateringslogik (PC-uppdatering) och instruktionshämt- ningslogik som används för alstring av en sekvens av instruktioner för exekvering av processorn som svar på programräknaren och resultaten av andra instruktioners exekvering. Instruktionshämtningslogiken tillhandahåller sålunda hantering av instruktions-cachar, förgrenings- instruktioner och liknande.

De funktionella enheterna 400 är kopplade till sys- tembussen via linje 401 genom ett bussgränssnitt. Linje 10 15 20 25 30 35 520 072 25 401 kan utgöra en eller flera bussar för transport av indata och utdata. Även instruktioner från ett instruk- tionsminne och adresser för hämtning av data och instruk- tioner tillhandahålls via bussgränssnittet. Inuti pro- cessorn tillhandahålls typiskt ett flertal generella register 402, vilka vanligtvis hänvisas till som en registerfil. Typiskt är den en treportsminnesenhet som tillhandahåller operander till de funktionella enheterna pà linjer 403 och 404 och tar emot resultat som skall lagras fràn de funktionella enheterna via linje 405.

I fig 4 visas programräknaren 406 som ett register som är oberoende av den generella registerfilen 402.

Självklart kan den i olika utföringsformer anses vara del av registerfilen. Programräknaren 406 är kopplad till programräknaruppdateringslogiken inuti de funktionella enheterna via linje 407 och matar tillbaka programräknar- värdena till de funktionella enheterna för användning av instruktionshämtningslogiken och andra lämpliga funk- tionella enheter via linjen 408.

Enligt föreliggande uppfinning är sålunda proces- sorns funktionella enheter anpassade till att känna igen JSRC-instruktionen och styra uppdateringen av programräk- naren som svar därpå.

Fig 5 visar en förenklad version av programräknar- uppdateringslogiken för användning i systemet i fig 4.

Såsom beskrivits ovan, i samband med fig 3, finns det JSR- och JSRC-instruktioner av varierande format för olika adresseringsformer, vilket innefattar ett första format som bär en operand i koden och ett andra format som bär en registeridentifierare som en del av instruk- tionen.

PC-uppdateringslogiken, som visas i fig 5, består väsentligen av en adderare 500 som adderar programräkna- rens värde PC från linje 501 med utsignalen frän en första väljare 502, vilken styrs av en signal som indikerar att JSRC-instruktionen har känts igen samt utsignalen från en andra väljare 503, vilken styrs av en 10 15 20 25 30 35 520 072 26 signal som indikerar att instruktionen bär en operand som I det fall en instruktion inte bär en operand är sålunda utsignalen upptar mer plats än instruktionen eller ej. från väljare 503 instruktionslängden, t ex 2 byte. I fallet där instruktionen bär en operand och avkodnings- logiken har låst operanden, är utsignalen från väljare 503 operandens längd, vilken i exemplet i fig 3 är 4 byte. Om instruktionen är en JSRC-instruktion måste utsignalen från väljaren 503 kombineras med längden hos kontext-datan i kod-område. Alltså väljer väljaren 502 antingen 0 byte om JSRC-instruktionen inte känns igen eller den förutbestämda kontext-längden om JSRC- instruktionen känns igen. Dessa tre värden adderas samman av adderaren 500 och förs tillbaka till programräknaren som det uppdaterade programräknarvårdet. I fallet med en JSRC-instruktion utnyttjas detta uppdaterade programräknarvårde av exceptionshanteraren för att hitta nämnda kontext-data i kod-område.

I utföringsformen i fig 5 är kontext-längden ett förutbestämt värde som är kopplat till en särskild JSRC- instruktion. I olika utföringsformer kan kontext-datans längd variera enligt behoven hos en särskild implementa- tion eller en speciell instans av hoppa-till-subrutin- instruktionen. Hoppa-till-subrutin~instruktionen kan sålunda tillhandahållas i mer än en instans för olika I detta fall dateringslogiken behöva känna igen den särskilda instan- kontext-längder. skulle programräknarupp- sen av JSRC-instruktionen och addera den lämpliga kontext-längden. Alternativt kan JSRC-instruktionen bära ett värde som en parameter, vilket är lika med kontext- längden som skall adderas till programräknaren. I detta fall kan kontext-längden hämtas från registerna för generella ändamål där den annars tillhandahålls av pro- cessorns funktionella enheter.

Fig 6 används för att beskriva processen för exekve- ring av JSR- och JSRC-instruktionerna enligt föreliggande uppfinning. På den första raden 600 beskrivs JSR-instruk- 10 15 20 25 30 b) U'| 520 072 27 tionen. När processorn exekverar instruktionen läser den först instruktionen, avkodar instruktionen och uppdaterar programräknaren till platsen som följer efter instruk- tionen i cykel l till cykel Nl. Från cykel Nl till cykel N2 läses operanderna om några sàdana burits med. Program- räknaren uppdateras till platsen efter operanderna. I cykel N2 för subrutinens átergàngsadress och alla därtill hörande till cykel N3 lagras programräknaren vid platsen enheter sàsom stackpekaren uppdateras i enlighet med standardexekveringsprocesserna för JSRC-instruktionen. I cykel N3 till N4 läses nästa instruktion vid målet för anropet och subrutinen exekveras.

I enlighet med JSRC-instruktionen, i cykel 1 till cykel Nl, ren uppdateras till platsen efter instruktionen.

Programräkna- I cykel läses och avkodas instruktionen.

Nl till cykel N2 läses operanderna och programräknaren uppdateras till platsen för operanden plus längden hos kontext-datan i kod-omràde, vilken i denna utföringsform är av en fast storlek. I cykel N2 till cykel N3 lagras programräknaren på platsen för àtergàngsadressen och alla därtill hörande enheter uppdateras. I cykel N3 till cykel N4 läses nästa instruktion vid anropsadressen och subrutinen exekveras.

Exceptionshanteraren behöver emellertid läsa kontext-datan i kod-omràde och använder en funktion av programräknarvärdet för att finna datan. Särskilt kommer inledningen av datan att bestämmas av en funktion som är lika med programräknarens värde plus en förskjutning av O minus kodordets längd. Pá detta sätt kopplas kontext- datan i kod-omràde automatiskt till anropsfunktionen.

Därtill stör inte kontext-datan i kod-omràde den normala behandlingen eller kostar extra cykler under normal exekvering.

Därav följer att kontexten eller en pekare till kontexten placeras vid àtergängsadressens förskjutning minus 4 i den föredragna utföringsformen. När väl àter- gàngsadressen är funnen, finner exceptionshanteraren lO 15 20 25 30 35 520 072 28 nämnda kontext-data i kod-område utan att behöva söka i tabeller och jämföra värden.

Informationen i nämnda kontext-data i kod-område är i denna utföringsform 4 byte eller 32 bitar. De 32 bitarna är antingen en kontext eller en kontext-pekare eller en kombination av båda. I den föredragna utföringsformen finns en föredragen uppställning av 32 bitar för data. Detta antagande kan användas för att vid de minst signifikanta bitarna koda huruvida de övriga av de 32 bitarna är en pekare eller verklig komprimerad kontext-data med någon information fastställd. Pseudokod för en exceptionshanterare och en stackvandrarfunktion som kan utnyttja nämnda JSRC-kontext-data i kod-omrâde hos föreliggande uppfinning följer sålunda: © Axis Communications AB 1998 /* Skaffa en pekare till kontext-informationen för funktionen med återgángsadressen "pc_return_location". Kom ihàg att byte-storlek (8 bitar). "char" är av Om kontexten är av den komprimerade sorten, expandera den in i strukturen i "expanded_context" innan en pekare till *that* (skrivs över vid nästa anrop) returneras. */ void *f(void **return_pc_stack_location) { static struct exception_context expanded_context; /* Förskjutning -l för ett objekt av pekarstorlek betyder förskjutning med -4, räknat i byte. */ void *context_or_pointer = return_pc_stack_location[-1]; /* Eftersom alla exceptionstabeller är uppställda pà adresser som är en multipel av tvà, kodar vi "komprimerad kontext"-egenskapen i de lägsta bitarna i den lämpliga pekaren; om den är noll, då är det en pekare, om l, är det en komprimerad kontext. */ 10 15 20 25 30 35 520 072 29 if((((unsigned long int) context_or_pointer) &l)==O) { /* Det var en pekare, returnera den bara. */ return context_or_pointer; } else { /* Komprimerad form */ Expandera den komprimerade formen fràn "context- _or_pointer" till "expanded_conteXt" return &eXpanded_context; } /* Vi råkar veta var àtergàngsadressen till anroparen av denna särskilda funktion (stack_walker) finns; den finns precis vid stackpekaren "sp", förskjutning -8.

Detaljer rörande flyttbarhet mellan system utelàmnas för koncishet. */ void stack_walker(void) { void**return_pc_location; struct exception_context *contextp; /* På-raden-assemblermagi för hämtning av stackpekarvärdet. asm("move.d sp, %O":"=rm" (return_pc_location)); return_pc_location=8; contextp = f(return_pc_location); /* Gàr helt enkelt i slinga genom anroparna (antagande att ingen har specificerat "throw()") med början 10 15 20 25 30 520 072 30 från denna funktion, användande kontext~tabeller.

Skriv återhoppsadressen för varje som ett exempel.

Oroas inte över den komprimerade konteXt-informa- "f(PC)" Grundanropet till "main()" och globala konstruktörer tionen, hanterar detta. är markerade med en "noll"-kontext; vi kommer att erhålla det som NULL. När vi erhåller det, stanna där.

(Föresten, om sökningen efter en hanterare når detta anropas "terminate()").

Denna slingkonstruktion kan även användas för implementering av slingdelen hos stackavnystning och exceptionshanterarsökning_*/ while { printf"Called from: (contextp !=NULL) %p\n", *return_pc_location); /* Uppdatera return_pc_location och kontext som är kopplad till denna anropare. */ return_pc_location =return_pc_location + contextp->offset_of_return_address; context+f(return_pc_location): } } Kompilatorn i en föredragen utföringsform av föreliggande uppfinning för språket C++ ansvarar för genereringen av exceptionstabeller. Enligt föreliggande uppfinning modifieras kompilatorn för tillhandahållande av en del av exceptionstabellerna eller en pekare till exceptionstabellerna såsom kontext-data i kod-område i samband med JSRC-instruktionen.

I det följande tillhandahålls en exemplifierande pseudokod av ett program där föreliggande uppfinnings 520 072 31 JSRC-instruktion skall användas i enlighet med språket C++.

KOCDQOWUWvD-UJNP-J 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 class To_be_thrown { public: {} To_be_thrown(char*message): the_message(*message) {} const char*message() {return the_message;} ~To_be_thrown() private: const char*the_message; }; class Foo { public: Foo(int a):va1ue(a){printf("Foo:%d ctor cal1ed\n", va1ue);} ~Foo() {printf("Foo:%d dtor cal1ed\n",value);} private: int value; }; extern void wont_throw(const char*) throw(); extern void maybe_throw(const char*); extern void indirect(void(*)(const char*), const char*); void midd1eman() { Foo foo_l(1); maybe_throw(This"); wont_throw("That"); Indirect(maybe_throw, "Whatever"); 27 28 29 30 31 32 33 34 35 36 27 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 U'l »Jä- UI U1 U'l ON 520 072 32 Foo foo_2(2) maybe_throw("Something"); } void indirect(void(*f)(const char*) { char s[lO]; strncpy(s,sc,9); f(S); } void doit(void) { try { middleman(); } catch(To_be_thrown what_is_thrown) printf("%s was thrown\n", what_is_thrown.message()); woid catchall() { try { doit(); } catch(...) I I printf("Something unknown was thrown\n")- } const char*sc) I lO 15 20 25 520 072 33 58 } 59 void maybe_thrown(const char*s) 6o{ 61 if (strcmp(s, "Whatever")==O) 62{ 63 throw(To_be_thrown("Gotcha!")); 64} 65} Här är ett exempel pà extraherad kod som kan använda JSRC-instruktionen. Catchall()-funktionen anropas fràn någon annanstans och är högst upp i anropskedjan för exemplet här och i fig 7.

Det första stället i programmet där JSRC~instruktio- nen utnyttjas är vid den första anropspunkten (rad 24), pà vilken exceptions-kontext-information utnyttjas. För detta exempel bör informationen innefatta hur foo_l skall (register osv) skall återstäl- destrueras, hur stackramen las från "middleman()", omfattande hur en àtergängsadress skall hittas. För rad 25 behövs ingen kontext-information eftersom funktionen "wont_throw" inte kommer att kasta nàgra exceptioner, vilket kan avläsas ur inte-kasta- "throw()"-attributet i dess deklaration. Vid nästa (rad 26) denna punkt behövs kontext-information angáende hur foo_2 anropspunkt lagras kontext-information. Vid skall destrueras, hur foo_l skall destrueras, hur stack- ramen fràn "middleman()" skall avnystas samt innefattande hur en àtergängsadress skall hittas. Nästa anropspunkt är till standardfunktionens "strncpy()" pà rad 33, men eftersom den aldrig kastar någon exception (känt av kompilatorn eller fràn en deklaration i dess listrubriks- fil som inte är inkluderad här), behövs ingen kontext- information, varför den normala JSR-anropsinstruktionen används. Anropspunkten efter detta är funktionen f(s) pà rad 34. Kontext-informationen för denna anropspunkt inne- fattar hur stackramen skall äterställas frän "indirect()" 10 15 20 25 30 35 520 072 34 innefattande hur en àtergàngsadress för "indirect" skall hittas. Därefter utnyttjas exceptionskontext-informatio- nen för "middleman()"-anropet pá rad 40. Denna informa- tion fångar klassen som skall kastas, anger vart det kastade objektet skall kopieras och hanterarens plats, anger hur stackramen fràn "doit()"-funktionen skall àterställas, innefattande hur en ätergàngsadress skall hittas. Nästa anropspunkt där en exceptions-kontext- information lagras är "doit()"-anropet pà rad 52 i catchall(). tionen att den fångar vad som helst, Vid denna punkt indikerar kontext-informa- identifierar hanterarens plats och anger hur stackramen skall àter~ ställas, innefattande hur àtergàngsadressen skall hittas.

I detta exempel kastas en exception på rad 63. Det kastade objektet skapas vid denna punkt. Sökningen efter en hanterare och stackavnystningen startar. Eftersom denna kod inte innehåller annan exceptionsinformation, avnystas stacken under sökning efter relevant exceptions- information.

Fig 7 illustrerar stackens tillväxt i enlighet med exempelkoden som beskrivits ovan. I detta exempel startas processen sålunda av ett anrop till "catchall"-funktio- nen. Stacken växer med en från anroparen på rad 700 ätergängsadress och sparar registerna som "catchall" kommer att besegra pá rad 701. "Catchall"-rutinen anropar “doit"~funktionen. Stacken växer genom lagring av äter- gångsadressen in till "catchall" pà rad 702 och sparade register som skrivs över av "doit" på rad 703 samt reserverar lagringsutrymme för objektet "what_is_thrown" pà rad 704, vilken kommer att fyllas i när exceptionen kastas, och ett motsvarande test-block hittas här.

"Doit"-funktionen anropar ”middleman”-funktionen. Vid denna punkt växer stacken med àtergàngsadressen in till "doit" (rad 705), kommer att besegra på rad 706, och reserverar lagrings- sparar registerna som "middleman" kapacitet för objekten foo_l och foo_2 pà rad 707 och 708. "Middleman"-funktionen anropar "indirect"-funktion- 10 15 20 25 30 520 072 35 en. När detta händer växer stacken genom lagring av åter- gàngsadressen in till "middleman" på rad 709, register som "indirect" kommer att skriva över på rad 710, och lagringskapacitet för den lokala grupperingen "s" på 711.

Funktionen "maybe_throw" anropas också. Vid denna punkt lagras àtergångsadressen in i "indirect" på rad 712 och register som "maybe_throw" kommer att skriva över och som är kända vid punkten för kastet lagras på rad 713. Väl i maybe_throw har villkoren för kastning av en exception uppnåtts och ett objekt av typen "to_be_thrown" kastas.

Stackavnystningen och sökningen efter en exceptions- hanterare använder kontext-informationen som är relaterad till den sparade ätergàngsadressen. Den omedelbara kon- texten hos kastfunktionen, vilken är sparade register och förskjutning av anroparens àtergångsadress, är känd vid kompileringstidpunkten och kan användas direkt vid "kastet".

Denna stack måste nystas av medelst en exceptions- hanterare såsom illustreras i fig 8. Vid programstarten, såsom indikeras vid block 800, är en parameter Exceptio- nerUnderBehandling noll och exceptionsstacken är tom.

Genom användning av ExceptionerUnderBehandling-räknaren blir det enkelt att spåra exceptioner som inte hanterats.

De exceptioner som inte fångas in av processen kommer att resultera i att räknaren inte är noll vid återgång.

Exceptionsstacksdatastrukturen används för omhändertagan- de av staplade exceptioner. Det händer att exceptioner kastas under destrueraranrop medan stackavnystning utförs, men detta omhändertas inuti destrueraranropet.

Exceptionsstacken möjliggör denna sorts behandling.

När en exception kastas såsom indikeras vid block 801, skapas ett temporärt ObjektAttKasta och nämnda ObjektAttKasta skjuts upp på exceptionsstacken. Lagringen för det kastade objektet är implementationsberoende.

Emellertid bör ett extrautrymme användas, företrädesvis separat från extrautrymmet (heap) från vilket nya objekt allokeras. Konstruktionen av det temporära objektet måste lO 15 20 25 30 35 520 072 36 skyddas från exceptionerna, möjligtvis genom addering av en tillstàndsvariabel (TempInCreation) som normalt är falsk och endast sann under tiden ett temporärt objekt skapas. Algoritmen fortsätter sedan med att sätta en funktionskontext lika med den aktuella längdplatsen hos kastets eller àterkastets punkt. Den ackumulerade kon- texten sätts lika med inga register för àterställning och exceptioner-under-behandling-variablen ökas (block 802).

Därefter sätts test-blocks-kontexten lika med funktions- (block 803). fig 7 är detta kontexten hos funktionen där "throw" kontextens test-blocks-kontext I exemplet i exekveras, "maybe_throw()" runt rad 713.

För varje par i test-blocks-kontextens objektlista, som indikeras vid block 804, anropas destrueraren för sådana objekt (block 805). När dessa processer anropar destruerare eller kopiekonstruktörer, mäste dessa anrop säkerställa att de inte släpper igenom nägra exceptioner.

Detta kan uppnàs genom insvepning av anropen i effekterna av ett "try{[anrop]}catch(...){terminate();}"-block.

Efter att destruerarna anropats söks hanterarlistan igenom efter test-blocks-kontexten för en hanterare som (block 806). Vid block 807 àstadkommes ett beslut baserat pà huruvida en motsvarar objektet som skall kastas hanterare hittats. I flödesschemat kan det se ut som om funktionsexceptionsdeklarationerna inte är utförda. Det är emellertid meningen att de skall implementeras av kompilatorn som adderar ett underförstått test-block, vilket skall vara det yttersta hos funktionen, som fångar alla överträdelser och transformerar dem till anrop till "unexpected()", "terminate ()" eller transformerar dem till verkan av "throw std::bad_exception".

Om hanteraren inte hittas vid block 807, då bestäm- mer algoritmen huruvida test-blocks-kontexten är den yttersta hos funktions-kontexten vid block 808. Om den är den yttersta, dä övergàr algoritmen till block 809. Vid denna punkt adderas funktions-kontexten till den ackumu- lerade kontexten. Denna process är insamlingen av effek- 10 15 20 25 30 520 072 37 terna av återställning av register och ackumulering av justeringar av stackpekaren. De behöver inte utföras direkt, men effekter måste kommas ihåg och utföras före hoppet till hanteraren. Också i detta block sätts funk- tions-kontexten lika med den yttre funktions-kontexten såsom en funktion av den aktuella funktions-kontexten.

Här är platsen för användningen av uppfinningen. Nämnda ”yttre funktionskontext” (outer function context) hittas genom användning av kodordet i kontext-anropsinstruktio- nen, oavsett om kontexten finns kodad i kodordet eller nås via en pekare till en tabell med kontext-informa- tionen. Nämnda "YttreFunktionsKontext ()"-funktion (”OuterFunctionContext()” function) är samma som funktionen hos programräknaren f(PC) som visas i fig 7.

Sålunda representerar pilen 720 i fig 7 tekniken för finnandet av funktions-kontexten som en funktion av programräknaren (t ex genom användning av JSRC-instruk- tionen) för den första anropspunkten som träffats på under avnystningen av stacken.

Efter block 809 går algoritmen tillbaka till block 803 för att upprepa processen. På detta sätt nystar pro- cessen av stacken följande vägen som visas i fig 7 från pil 720 till pil 721 till pil 722 till pil 723 till pil 724, pil 725, pil 726, pil 727, pil 728 ända till dess att ett test-block med en "catch" kastade objektets typ har hittats.

Om, vid block 808, den yttersta hos funktions-kontexten, då sätts test- blocks-kontexten lika med yttre test-block (test-blocks- kontext) och algoritmen går tillbaka till block 804 för som motsvarar det test-blocks-kontexten inte var genomgång av den nya kontext-informationen. Denna process går helt enkelt igenom en lista, oavsett om det är en länkad lista eller en tabell eller en annan implemente- ring, av objektlistan samt hanterarlistan i kontext- informationen (block 810).

Om en hanterare hittades vid block 807, går algorit- men till block 811. Vid block 811 kopieras objekten som lO l5 20 25 520 072 38 är specificerade i hanterarbeskrivningstrippeln. Nämnda ExceptionerUnderBehandling-räknare minskas med 1, stack- pekaren och andra register återställs medelst den ackumulerade kontexten, och programmet hoppar till hanteraren. Därefter, när hanteraren lämnar test-blocket, avslutas funktionsramen och anropas destrueraren för det aktuella objektet som skall kastas vid block 812. Minnes- platsen för objektet som skall kastas avallokeras och algoritmen återgår till normal exekvering. Om exceptionen kastas igen efter block 811, går processen tillbaka till återkastningsblocket vid 813. Det första steget i åter- kastningsblocket är att bestämma huruvida exceptions- stacken är tom vid block 814. Om så är fallet, avslutas processen, block 815. Om exceptionsstacken inte är tom, sätts exceptionsobjektet in i toppen av exceptionsstacken (block 816), och processen går tillbaka till block 802.

Beskrivningen ovan av en föredragen utföringsform av uppfinningen har presenterats i avsikten att illustrera och beskriva. Den är inte avsedd att vara uttömmande eller att begränsa uppfinningen till de exakta utföran- dena som beskrivits. Det är tydligt att många modifie- ringar och variationer kommer att vara uppenbara för fackmän inom området. Avsikten är att uppfinningens omfång skall definieras av de efterföljande kraven och deras ekvivalenter.

Claims (18)

10 15 20 25 30 h.) Ul 520 072 39 Patentkrav

1. l. Databehandlingssystem för att svara pà instruk- tioner i en uppsättning av instruktioner för exekvering av en process, vilket system innefattar: instruktionshämtningslogik som är anordnad att hämta instruktioner i uppsättningen av instruktioner för till- handahållande av en sekvens av instruktioner som svar på en instruktionspekare, vilken uppsättning av instruktio- ner innefattar en kontext-anropsinstruktion med en normal längd följd av kontext-data i kod-område med en bestämd längd, som används vid exekvering av en exceptionshanterare, vilken är anordnad att svara pà kontext-anropsinstruktionen; instruktionsavkodningslogik, som är kopplad till instruktionshämtningslogiken, vilken är anordnad att avkoda en aktuell instruktion i sekvensen som skall exekveras och omfattar logik för detektering av kontext- anropsinstruktionen; exekveringsresurser, som är kopplade till instruk- tionsavkodningslogiken och är anordnade att exekvera de avkodade instruktionerna; och logik, som är kopplad till instruktionshämtnings- logiken, vilken är anordnad att uppdatera instruktions- pekaren som svar pà detekteringen av kontext-anrops- instruktionen genom instruktionsavkodningslogiken, så att instruktionspekaren hoppar över nämnda kontext-data i kod-område till en annan instruktion i sekvensen.

2. System enligt krav l, innefattande ett program- minne, som är kopplat till instruktionshämtningslogiken, i vilket minne instruktioner i instruktionsuppsättningen lagras pà platser som är ätkomliga som svar pä instruk- tionspekaren och i vilket kontext-datan i kod-område lagras efterföljande kontext-anropsinstruktionen med en förskjutning pà noll eller flera byte, varvid logiken som uppdaterar instruktionspekaren är anordnad att hoppa över 10 15 20 25 30 35 520 072 40 ett datafält vid förskjutningen med en längd som är lika med den bestämda längden.

3. System enligt krav 1, varvid instruktionssekven- sen innefattar en eller flera funktioner som kännetecknas av avnystningsinformation, vilken används för avnystning av nämnda en eller flera funktioner för behandling av kontext-anropsinstruktionen, och varvid kontext-datan i kod-omràde åtminstone innefattar en delmängd av avnystningsinformationen.

4. System enligt krav 1, varvid instruktionssekven- sen innefattar en eller flera funktioner som kännetecknas av layoutinformation avseende funktionsargumentens layout i nämnda en eller flera funktioner, och varvid kontext- datan i kod-område åtminstone innefattar en delmängd av layoutinformationen.

5. System enligt krav 1, varvid nämnda kontext-data i kod-område innefattar en pekare till en minnesplats där information avseende en kontext för kontext-anrops- instruktionen lagras.

6. System enligt krav 1, varvid nämnda kontext-data i kod~omräde innefattar omedelbar kontext-data.

7. System enligt krav 1, varvid nämnda kontext-data i kod-område innefattar ett flertal databyte, omfattande ett fält för specificering av ett format för flertalet byte.

8. System enligt krav 7, varvid fältet indikerar huruvida flertalet byte innefattar omedelbar kontext-data och huruvida flertalet byte innefattar en pekare till kontext-data i en annan minnesposition.

9. System enligt krav 1, varvid den bestämda längden av nämnda kontext-data i kod-område innefattar en förut- bestämd längd.

10. Metod för behandling av instruktioner i ett databehandlingssystem, innefattande: lagring av en uppsättning av instruktioner i adresserbart minne, vilken uppsättning av instruktioner omfattar en kontext-anropsinstruktion med normal längd lO 15 20 25 30 520 072 41 följd av kontext-data i kod-område med en bestämd längd, som utnyttjas vid exekvering av en exceptionshanterare, vilken svarar pà kontext-anropsinstruktionen; hämtning av en sekvens av instruktioner fràn minnet som svar på en instruktionspekare, vilken identifierar en adress i det adresserbara minnet; avkodning av en aktuell instruktion i sekvensen, om- fattande detektering av kontext-anropsinstruktionen; uppdatering av instruktionspekaren med kontext- anropsinstruktionens normala längd plus den bestämda längden av nämnda kontext-data som svar pà detekteringen av kontext-anropsinstruktionen, annars uppdatering av instruktionspekaren med den aktuella instruktionens längd; anropning av en exceptionshanterare om villkoren för exceptionen infrias; och som svar på anropning av exceptionshanteraren, läs- ning av kontext-informationen i kod-område för exceptionshanteraren vid en adress i det adresserbara minnet som bestämts som svar på en funktion av instruktionspekaren.

11. Metod enligt krav 10, varvid funktionen av instruktionspekaren innefattar en adress som är baserad pà instruktionspekaren minus kontext-informationens bestämda längd.

12. Metod enligt krav 10, varvid kontext-informa- tionen innefattar en pekare till en minnesposition där kontext-data kopplad till kontext-anropsinstruktionen lagras.

13. Metod enligt krav 10, varvid kontext-informa- tionen innefattar omedelbar kontext-data.

14. Metod enligt krav 10, varvid kontext-informa- tionen innefattar ett flertal databyte, omfattande ett fält för specificering av ett format hos flertalet av byte.

15. Metod enligt krav 14, varvid fältet indikerar huruvida flertalet av byte innefattar omedelbar kontext- 10 15 520 072 42 data och huruvida flertalet av byte innefattar en pekare till kontext-data pà en annan minnesposition.

16. Metod enligt krav 10, varvid sekvensen av instruktioner innefattar en eller flera funktioner som kännetecknas av avnystningsinformation, vilken används för avnystning av nämnda en eller flera funktioner för behandling av kontext-anropsinstruktionen, och varvid nämnda kontext-data i kod-område åtminstone innefattar en delmängd av avnystningsinformationen.

17. Metod enligt krav 10, varvid sekvensen av instruktioner innefattar en eller flera funktioner som kännetecknas av layoutinformation avseende layouten hos funktionsargument i nämnda en eller flera funktioner, och varvid nämnda kontext-data i kod-omràde åtminstone innefattar en delmängd av layoutinformationen.

18. Metod enligt krav 10, varvid den bestämda längden av nämnda kontext-data i kod-område innefattar en förutbestämd längd.