home bbs files messages ]

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