announce: my very first disassembler now available (GPL)
in [ASM]
|
From: Alexei A. Frounze on 17 Aug 2008 01:15 On Aug 16, 10:08 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote: > There's also a special case in 64-bit mode. Depending on the rex > prefix (AFAIR, bit B) it can be either NOP or XCHG. I meant to say, if both operands are rAX, then it's NOP. This is controlled by mod, REX.R (if REX is present), reg, REX.B (if REX is present) and r/m. Alex
From: Willow on 18 Aug 2008 13:26 On Aug 16, 9:08 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote: [snip] > FPU instructions are generally encoded the same way as non-FPU > instructions if there's a memory operand (i.e. mod<3). The same is > often true about FPU instructions that don't have a memory operand, > but not always. E.g. there's FSTSW AX that seems to be valid/existent > only for AX and the r/m field often denotes not some register but a > particular instruction (i.e. further extends the opcode), e.g. F2XM1 > through FCOS. [snip] The problem was, I didn't have any handling in my table format for 2- byte opcodes like d9 f4 (fxtract) or (gasp!) 66 0f 38 01 (phaddw) which is really a 2-byte opcode (38 01) with two opcode prefix bytes (66 0f). I just added support to crudasm for two-byte opcodes, and as a test I added fxtract which someone pointed out to me was missing (hey if they notice, I'll add it!) It should be a breeze now to add 3DNow! instructions (there's already handling built in for it, but what's this about them having a "dummy" modr/m byte? I undertand they always have a modr/m byte, what makes it a "dummy"???) It should also be easy to add MMX, SSE, etc. instructions now that 2- byte opcodes are handled (I already have handling for opcode prefixes including 0f, 66, f2, and f3). I need to add more instructions to x86s/in_script.txt -- check out that file if you want to learn how crudasm works; the programs in the x86s/ directory generate out_* files from that one file in_script.txt. Cool, huh? The latest version is here: http://code.google.com/p/vm64dec/downloads/list Willow
From: Alexei A. Frounze on 19 Aug 2008 01:59 On Aug 18, 10:26 am, Willow <wrschlan...(a)gmail.com> wrote: > On Aug 16, 9:08 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote: > [snip]> FPU instructions are generally encoded the same way as non-FPU > > instructions if there's a memory operand (i.e. mod<3). The same is > > often true about FPU instructions that don't have a memory operand, > > but not always. E.g. there's FSTSW AX that seems to be valid/existent > > only for AX and the r/m field often denotes not some register but a > > particular instruction (i.e. further extends the opcode), e.g. F2XM1 > > through FCOS. > > [snip] > > The problem was, I didn't have any handling in my table format for 2- > byte opcodes like d9 f4 (fxtract) or (gasp!) 66 0f 38 01 (phaddw) > which is really a 2-byte opcode (38 01) with two opcode prefix bytes > (66 0f). Yeah, as long 0x66, 0xF* aren't disassemblied as prefixes for these special instructions, it should be OK. > I just added support to crudasm for two-byte opcodes, and as > a test I added fxtract which someone pointed out to me was missing > (hey if they notice, I'll add it!) It should be a breeze now to add > 3DNow! instructions (there's already handling built in for it, but > what's this about them having a "dummy" modr/m byte? I undertand they > always have a modr/m byte, what makes it a "dummy"???) Oops, sorry. From the opcode encoding and the fact that the same FPU registers were used (as with MMX) I got an impression that they actually ignored the ModR/M/SIB/disp bytes, at least partially. I should've used them. :) > It should also be easy to add MMX, SSE, etc. instructions now that 2- > byte opcodes are handled (I already have handling for opcode prefixes > including 0f, 66, f2, and f3). > > I need to add more instructions to x86s/in_script.txt -- check out > that file if you want to learn how crudasm works; Not really. I've done a lot of assemblying and disassemblying, there isn't much interesting left in those two processes themselves, rather in programs they're applied to. :) > the programs in the > x86s/ directory generate out_* files from that one file in_script.txt. > Cool, huh? You know it better, so, sure. :) Alex
From: H. Peter Anvin on 19 Aug 2008 17:03 Alexei A. Frounze wrote: > On Aug 16, 10:08 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> > wrote: >> There's also a special case in 64-bit mode. Depending on the rex >> prefix (AFAIR, bit B) it can be either NOP or XCHG. > > I meant to say, if both operands are rAX, then it's NOP. This is > controlled by mod, REX.R (if REX is present), reg, REX.B (if REX is > present) and r/m. Except, it's not. Plain 90h, which would normally be XCHG EAX,EAX (and therefore zero-extend EAX into RAX) is actually NOP. -hpa
From: Alexei A. Frounze on 19 Aug 2008 23:26
On Aug 19, 2:03 pm, "H. Peter Anvin" <h...(a)zytor.com> wrote: > Alexei A. Frounze wrote: > > On Aug 16, 10:08 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> > > wrote: > >> There's also a special case in 64-bit mode. Depending on the rex > >> prefix (AFAIR, bit B) it can be either NOP or XCHG. > > > I meant to say, if both operands are rAX, then it's NOP. This is > > controlled by mod, REX.R (if REX is present), reg, REX.B (if REX is > > present) and r/m. > > Except, it's not. > > Plain 90h, which would normally be XCHG EAX,EAX (and therefore > zero-extend EAX into RAX) is actually NOP. I might have misspoken, but the appropriate REX followed by 0x90 isn't a NOP, it's XCHG rAX, r8. Excerpt from the AMD's manual on XCHG: XCHG Exchange Exchanges the contents of the two operands. The operands can be two generalpurpose registers or a register and a memory location. If either operand references memory, the processor locks automatically, whether or not the LOCK prefix is used and independently of the value of IOPL. For details about the LOCK prefix, see Lock Prefix on page 10. The x86 architecture commonly uses the XCHG EAX, EAX instruction (opcode 90h) as a one-byte NOP. In 64-bit mode, the processor treats opcode 90h as a true NOP only if it would exchange rAX with itself. Without this special handling, the instruction would zero-extend the upper 32 bits of RAX, and thus it would not be a true nooperation. Opcode 90h can still be used to exchange rAX and r8 if the appropriate REX prefix is used. This special handling does not apply to the two-byte ModRM form of the XCHG instruction. Table A-1 also lists both NOP and XCHG r8, rAX in the cell for opcode 0x90. Alex |