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.

[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
.

Relevant Pages

  • Re: .Code Start and End
    ... Do you mean individual instructions themselves? ... Next you have opcode byte. ... Next you have an optional ModR/M byte. ... implies a 1-byte immediate at the end, ...
    (alt.lang.asm)
  • Re: Are prefix opcodes better than variable length?
    ... have grown *huge* numbers of new instructions, ...  Arranging some of that to allow for a easy VLE ... decide they really don't want to do VLE, and just use the extra opcode ... done anyway to allow for future expansion of the ISA. ...
    (comp.arch)
  • Re: GAS-style syntax issue...
    ... when parsing each opcode, it initially starts off assuming that the ... a 'GAS' flag is set for the opcode. ... A few instructions end in two size letters like the sign-extended move ... movq, you end up with 'mov' as the instruction, when one choice is 'mov' ...
    (alt.lang.asm)
  • Re: Expanding opcode question
    ... > xxx instructions with yyy registers ... In effect this is a two bit opcode. ... Design an expanding opcode to allow all the ...
    (comp.programming)
  • Re: random ISA idea...
    ... was used effectively in my own VM bytecode designs, ... If you count different address modes as different instructions, x86 has more instructions than what you have provided. ... not sure why an 8 or 16 bit opcode would be a big issue. ... mostly it is that having to calculate stuff in registers, ...
    (comp.arch)