Campus Helsingborg IDA2 Hantering av hazards i multi-pipelines Av: Mounir Salam
Abstract Det finns tre olika problem som kan uppstå när vi kör en pipeline med flera steg. De tre problemen även så kallade hazards är data, strukturell och kontroll hazard. Hantering av konflikterna som uppstår i hazarden är olika beroende vilken vi tallar om. i denna rapport kommer du att få en lite mer förståelse av vad de olika hazarden gör och hur du kan göra för att lösa dem. Introduktion Det viktiga med pipeline är att vi kan köra flera instruktioner samtidigt men det kan uppstå ett par problem på vägen så kallade hazards. Hazards är det största problemet i en pipeline och om det inte finns en lösning för at ta bort hazarden skulle vi inte kunna ha en pipeline. I rapporten kommer vi att gå igenom de olika hazardsen, vilka problem de medför och hur vi hanterar dem på ett enkelt sätt med hjälp av till exempel stall. Hazards och konflikt hantering av hazards Att skriva en kod och exekvera den är ett lätt jobb för användaren men när det uppstår ett fel i koden kan det vara lite mer problematiskt för användaren för att det kan uppstå någonting som kallas för en hazard inom pipelinenen. Det finns tre olika sorters hazards och vi ska gå igenom här näst. Kontroll hazard: Under exekvering av ett program så kan vi ibland behöva använda oss av hopp även så kallad branch för att exekvera en annan instruktion som ligger längre fram än där hoppet finns. Men det är där problemet uppkommer för att hoppet vill exekvera till exempel instruktion 69 medan nästa instruktion efter är instruktion 39 det är vad vi kallar för en kontroll hazard. o Det finns tre sätt att lösa kontroll hazards på vilka är pipeline bubbling, delayed branching och branch prediction. när en konflikt mellan instruktioner uppstår kan man lösa de genom att lägga en stall framför instruktionen tills den kan köra som normalt igen. o Den första vi kommer att snacka om är pipeline bubbling. Pipeline bubbling är et annat namn för stall och används inte bara för kontroll hazard men för alla de andra hazarden. o Den andra vi kommer att prata lite mer om är delayed branching. Istället för att göra stalls vill man att processorn ska göra någonting och det är tanken med delayd branching. Det finns två alternativ i en kontroll hazard när det
gäller villkorliga hopp, det ena är om hoppet görs eller om hoppet inte görs. Om vi exekverar koden och Z-flaggan blir triggad då kommer hoppet att göras på grund av att det är en BEZ och det leder till att vi kommer att få en penalty på tre cykler och om hoppet inte görs kommer vi att få en penalty på två cykler. Skillnaden med delayed branching är att istället för att göra instruktionen direkt efter hoppet så låter man processorn göra något emellan åt. Då kommer vi att få en penalty på två cykler istället för tre vid ett villkorligt hopp och en cykel vid ett ovillkorligt hopp. o Den tredje vi kommer att prata mer om är branch prediction. Istället så gör vi ett antagande på att nästa instruktion som exekveras är inget hopp, om vi gissat rätt och inget hopp görs då får vi bara en penalty på en cykel om vi gissat fel så kommer hoppet att göras och vi får en penalty på två cykler. Samma sak händer om vi gör ett antagande på om ett hopp görs gissar vi rätt får vi en penalty på en cykel och om vi gissat fel får vi en penalty på två cykler då kommer hoppet att inte göras. Strukturell hazard: Problemet som uppstår vid strukturell hazard är när två instruktioner vill använda minnet samtidigt vilket leder till ett stop. Om vi sätter till en stall till instruktionen där problemet uppstår får vi en penalty på en cykel. o Det finns ett enkelt sätt att lösa problemet med strukturell hazard och det är genom att istället för att ha ett minne för alla instruktioner så kan vi dela upp cacheminnena till en som tar hand om data och en som tar hand om instruktioner Data Hazard: Data hazard uppstår när två instruktioner sker samtidigt och den andra instruktionen ska använda variabeln i den första instruktionen som inte är klar än kommer det att ske ett problem i pipelinen. Det finns sätt där ett data hazard kan uppkomma och det skriver Muhammad, Z, Saadia, A, Rabia, R, Nabila, R (2016) i artikeln How Data Hazards can be removed effectively om. De fyra sätten som Muhammad et al. (2016) skriver om är RAW, WAR, WAW och jag tänker förklara dem lite mer. o RAW står för Read After Write, detta sker när instruktion två är före än instruktion ett och instruktion två vill läsa in före än instruktion ett har skrivit klart. Det som kommer att hända är att instruktion två vill ha värdet av instruktion ett men instruktion ett har inte skrivits klart och det sker en data hazard. o Det som sker i WAR (Write After Read) är att instruktion två vill skriva destinationen till instruktion ett innan instruktion ett läser destinationen.
o WAW ( Write After Write) sker när instruktionen två vill skriva en operand innan instruktion ett skriver operanden. o De två sätten vi kommer att ta upp om hur man kan lösa problemet på data hazard är re-schedule och register renaming. o I data hazard vet vi att hazarden uppstår på grund av att instruktionerna vill ta ett värde innan den är klar. Detta går att fixa genom att använda rescheduling genom att till exempel ladda in alla värden innan man går vidare med instruktionerna som vi ser i den här bilden o I artikeln 'The design space of register renaming techniques' skriver Sima, D (2000) om hur en processor kan skriva till ett annat register i adress rymden så man inte kommer i kontakt med en hazard. Om en instruktion två ska läsa in värdet av instruktion ett men instruktion ett är inte klar kommer det att uppstå en hazard. Det som kommer att hända är att instruktionen kommer att temporärt ändras till exempelvis r33. Instruktionen register byter namn och då kommer resultatet att skrivas in i r33 istället för det föra registret. Enligt Sima, D (2000) måste referenserna till source registret omdirigeras till där det nya registret finns. Slutsats I denna rapport har vi visat hur man tar hand om konflikter i multi-pipeline inom de olika hazarden. Vi har märkt att pipeline bubbling är en allmän lösning inom alla typer av hazard och att olika typer av hazard har olika lösningar beroende på vad problemet är.
Referenser Muhammad Zeeshan, Saadia Anayat, Rabia and Nabila Rehman,, How Data Hazards can be removed effectively, International Journal of Scientific & Engineering Research, Volume 7, Issue 9, September-2016 Sima, D 2000, 'The design space of register renaming techniques', IEEE Micro, 20, 5, pp. 70-83, Inspec Bild: Erik Larssons föreläsning 2 http://www.eit.lth.se/fileadmin/eit/courses/eitf60/f%d6/f%d62.17.pdf