Ik ben statisch bezig met het omkeren van software die is gecompileerd voor een Atheros AR7161 met radare2. Deze processor implementeert MIPS, en ik herinner me dat MIPS een vertragingsslot heeft. Dit is inderdaad merkbaar in de demontage, omdat ik instructies kan zien die logisch zouden moeten worden uitgevoerd voordat takken er direct achter worden geplaatst.
Tijdens het analyseren van een stukje code kwam ik echter een beqz-instructie tegen waarvoor ik aannam dat de instructie nadat deze eerst zou moeten worden uitgevoerd, heeft geen zin in de context van het programma. Ik moet toegeven dat mijn analyse verkeerd kan zijn, wat niet onwaarschijnlijk is; ik heb echter enige twijfels dat ik “ook graag zou willen wissen:
-
Gebruik alle branch / jump-instructies altijd de branch delay-slot zodat de instructie direct daarna logischerwijs als eerste moet worden uitgevoerd ? Zo niet, in welke gevallen zou het niet?
-
Is er een manier om radare2 de logische uitvoeringsvolgorde te laten zien in plaats van degene die in het binaire bestand is gecodeerd?
Bewerken : concreet heb ik te maken met de volgende reeks:
beqz v0, <some address> lb v0, 0x40(sp) Ik heb een erg diffuus beeld in mijn hoofd over deze instructie die de pijplijn ingaat. Ik kan me voorstellen dat de tweede instructie wordt opgehaald terwijl de eerste wordt gedecodeerd; vandaar , zou de uitvoering van het vertragingsslot eigenlijk moeten starten. De vertakkingsinstructie hangt er echter van af dat hetzelfde register wordt gewijzigd door de instructie in het vertragingsslot, dus wat zal er gebeuren? Zal de vertakkingsinstructie de toestand evalueren met behulp van het oude register va lue, of de nieuwe bijgewerkt door lb?
Bedankt
Reacties
- Misschien heb je baat bij het lezen van de MIPS-serie door Raymond Chen hier: link Het eerste antwoord is nee (en zie de link voor details). Ik kan ' de tweede niet beantwoorden.
Antwoord
De instructie in de vertragingssleuf wordt geëvalueerd na de vertakking (of sprong) instructie. De uitvoering van de instructie in het vertakkingsslot heeft geen invloed op de evaluatie van de vertakkingsvoorwaarde.
Ik heb waargenomen dat het vertragingsslot voor een paar dingen wordt gebruikt:
- Laatste instructie van basisblok dat leidt naar de branch-instructie
- Branch-test zal niet afhankelijk zijn van de uitvoer van de berekening van de branch delay slot-instructie
- Vaak gezien bij onvoorwaardelijke sprongen / branches zoals
b,jal
- De eerste instructie van het doorvalblok .
- Er mogen geen bijwerkingen aanwezig zijn als de tak wordt ingenomen.
- Analyse zal aantonen dat eventuele registers niet nodig zijn in het geval de tak wordt ingenomen.
- De eerste instructie van block als de branch wordt gebruikt
- Als er meerdere paden zijn naar het branch-doel, zal deze instructie waarschijnlijk meerdere keren worden gezien met de verschillende branches
- Het laden van een voorwaardelijke waarde, vaak voor retourwaarden
Dit artikel gaat in detail over vertakkingsslots.
Zoals opgemerkt door Igor, houdt de “waarschijnlijke” versie van de vertakkingsinstructie de effecten van de instructie alleen in het vertragingsslot als de instructie daadwerkelijk wordt gebruikt.
Antwoord
- Er zijn variaties op voorwaardelijke vertakkingen genaamd “branch [op voorwaarde] waarschijnlijk”, bijv.
-
bgezl– Branch op groter dan of gelijk aan nul waarschijnlijk -
beql– Branch op Gelijk waarschijnlijk
-
Deze instructies hebben een vertragingsslot, maar de instructie in het vertragingsslot wordt alleen als de branch is bezet. Als de vertakking niet wordt genomen, is de instructie in de vertragingssleuf niet uitgevoerd ( geannuleerd ) .
NB: deze instructies zijn verwijderd in Release 6 van MIPS Architecture. Het voegde ook compacte variaties toe van branches die geen vertragingsslots hebben
Wat betreft je fragment, ik vermoed sterk dat de branch de oude registerwaarde gebruikt, maar je kunt het waarschijnlijk bevestigen alleen door het op een daadwerkelijke processor te laten draaien.