Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,683 of 4,675    |
|    R.Wieser to All    |
|    Interpreting (the data following) a floa    |
|    04 Dec 18 18:47:29    |
      From: address@nospicedham.not.available              Hello all,              I'm disassembling a program using IDA Freeware (an older version, non       graphical), and am encountering multiple INT 0x35 (and friends)       instructions. Which is commented as a floating-point emulation. Full       stop.              Ralf Browns interrupt list shows it to be emulating the 0xD9 machine opcode.       Again, full stop.              Looking in the "The IA-32 Intel Architecture Software Developer's Manual,       Volume 2 - Instruction Set Reference (24547112).pdf" document I can find       multiple entries having the 0xD9 opcode, and from it I take it that the       bytes following the above INT 0x35 are also playing a role: 0x7E 0xFA 0x8A       ...              But I do have a bit of a problem interpreting the document. One of the       entries says:              [quote]       D9 /6 FNSTENV* m14/28byte Store FPU environment to m14byte or m28byte       without checking for pending unmasked floating-point exceptions. Then mask       all floating-point exceptions.       [/quote]              I have abslutily *no* idea how to match it up with the 0x7E opcode folowing       the INT 0x35. The explanation for the "/6" is as follows:              [quote]       /digit-A digit between 0 and 7 indicates that the ModR/M byte of the       instruction uses       only the r/m (register or memory) operand. The reg field contains the digit       that provides an       extension to the instruction's opcode.       [/quote]              I'm not at all sure what that means, and if the "/6" actually means that it       matches up with the low three bits of the 0x7E byte. Also, there seems to       be no info on how the "reg field" should be interpreted. And why the "mod"       bits (upper two) are both not just clear or set, as they do not seem to have       any function here(?).              In other words, help ? I could do with a bit of explanation of the       explanation I'm afraid. :-(              Regards,       Rudy Wieser              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca