Re: announce: my very first disassembler now available (GPL)

On Aug 18, 10:26 am, Willow <wrschlan...@xxxxxxxxx> wrote:
On Aug 16, 9:08 pm, "Alexei A. Frounze" <alexfrun...@xxxxxxxxx> 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.


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. :)