Inversez static unele programe compilate pentru un Atheros AR7161 folosind radare2. Acest procesor implementează MIPS și îmi amintesc că MIPS are un slot de întârziere a ramurilor. Acest lucru se observă într-adevăr în demontare, deoarece pot vedea instrucțiuni care ar trebui executate logic înainte ca ramurile să fie plasate imediat după ele.
Cu toate acestea, în timp ce analizam o bucată de cod, am dat peste o instrucțiune beqz pentru care presupunând că instrucțiunea după ce ar trebui să se execute mai întâi nu are sens în contextul programului. Trebuie să recunosc că analiza mea ar putea fi greșită, ceea ce nu este puțin probabil; totuși, am unele îndoieli că aș vrea să șterg și:
-
Toate instrucțiunile de ramificare / salt utilizează întotdeauna slotul de întârziere a ramurii astfel încât instrucțiunea imediat după aceea să se execute mai întâi logic ? Dacă nu, în ce cazuri nu?
-
Există vreo modalitate de a face ca radare2 să afișeze ordinea de execuție logică mai degrabă decât cea codificată în binar?
Editați : concret, am de-a face cu următoarea secvență:
beqz v0, <some address> lb v0, 0x40(sp) Am o imagine foarte difuză în cap despre aceste instrucțiuni care intră în conductă. Pot imagina a doua instrucțiune preluată în timp ce prima este decodificată; , executarea slotului de întârziere a ramurii ar trebui să înceapă de fapt. Cu toate acestea, instrucțiunea de ramură depinde de același registru modificat de instrucțiunea din slotul de întârziere a ramurii, deci ce se va întâmpla? Instrucțiunea de sucursală va evalua starea folosind vechiul registru va lue, sau noul actualizat de lb?
Mulțumesc
Comentarii
- S-ar putea să beneficiați de citirea seriei MIPS de Raymond Chen aici: link Primul răspuns este nu (și consultați linkul pentru detalii). Nu pot ' să răspund la al doilea.
Răspunde
Instrucțiunea din slotul de întârziere a ramurii este evaluată după instrucțiunea de ramificare (sau salt). Executarea instrucțiunii în slotul de întârziere a sucursalei nu are impact asupra evaluării stării sucursalei.
Am observat că slotul de întârziere a sucursalei este folosit pentru câteva lucruri:
- Ultima instrucțiune a blocului de bază care duce la instrucțiunea de ramificare
- Testul de ramură nu va depinde de ieșirea calculului instrucțiunii slotului de întârziere a sucursalei
- Văzut în mod obișnuit cu salturi / ramuri necondiționate ca
b,jal
- Prima instrucțiune a blocului de cădere prin .
- Nu ar trebui să existe efecte secundare dacă este luată ramura.
- Analiza va arăta că nu este nevoie de registre afectate în cazul în care ramura este luată
- Prima instrucțiune a blocului dacă ramura este luată
- Dacă există mai multe căi către ținta ramificării, această instrucțiune va fi probabil văzută de mai multe ori cu diferitele ramuri
- Încărcarea unei valori condiționale, adesea pentru valorile returnate
Acest articol intră în detaliu despre sloturile de întârziere a ramurilor.
După cum a remarcat Igor, versiunea „probabilă” a instrucțiunii de ramificare păstrează efectele instrucțiunii în slotul de întârziere a ramurilor numai dacă instrucțiunea este efectiv luată.
Răspuns
- Există variații ale ramurilor condiționale numite „ramură [cu condiția] probabilă”, de ex.
-
bgezl– Sucursală mai mare decât sau egală cu zero probabil -
beql– Sucursală pe La fel de probabil
-
Aceste instrucțiuni au un slot de întârziere, dar instrucțiunile din slotul de întârziere sunt executate numai dacă ramura este luată. Dacă ramificația nu este luată, instrucțiunea din slotul de întârziere este nu executată ( anulată ) .
NB: aceste instrucțiuni au fost eliminate în versiunea 6 a MIPS Architecture. De asemenea, a adăugat variații compacte ale ramurilor care nu au sloturi de întârziere
În ceea ce privește fragmentul dvs., bănuiesc cu tărie că sucursala folosește valoarea registrului vechi , dar probabil o puteți confirma numai executându-l pe un procesor propriu-zis.