Timeline for Help with FISTP and FILD interpretation
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 29 at 20:02 | vote | accept | Uddie | ||
| Aug 29 at 19:59 | comment | added | Uddie | First of all, sorry for late reply. Yes, you are right, it all seems clear for me now. Thank you for explanation. | |
| Aug 23 at 19:36 | answer | added | blabb | timeline score: 2 | |
| Aug 23 at 18:40 | comment | added | Ali Rizvi-Santiago |
...that is assuming that there's no other instructions tampering with [esp+0x10] in between the two instructions you listed. (Related question: reverseengineering.stackexchange.com/questions/20559/…, link for answer is archived at web.archive.org/web/20071006182549/http://www.ray.masmcode.com/…)
|
|
| Aug 23 at 18:34 | comment | added | Ali Rizvi-Santiago |
Intel's floating point instructions are based on a stack. fist stores a 16-32-64-bit floating point number (IEEE) to the operand address, whereas fild loads from an address into the stack. The p suffix, is the variation of fist that pops the first value, ST(0), from said stack. The values you're seeing are not the underlying operand changing the address, but rather that before fistp is run, the value is 0x1cf8. After executing fistp, however, ST(0) is popped and written to [esp+0x10] as 0x2c36. When execution gets to fild, the previous value of ST(0) was already written.
|
|
| Aug 22 at 22:12 | history | asked | Uddie | CC BY-SA 4.0 |