Ulrich Weigand wrote:
> > The problem
> > is that byte- and word/long- instructions
> > have separate opcodes, and as far as I can
> > see you lose this infomation when you call
> > decode().
>
> The information is certainly present (I am using this very code
> in a i386 emulator I've written - if there's enough data to correctly
> *emulate* the instruction, there should be enough to display it
> correctly ;-))
That's not really true. When you emulate a processor,
you handle each instruction separately, and so you can
have a "special case" for each instruction. However,
writing a disassembler that way would be maddening..
> You need to access the sizes of the single operands: op[i].size.
> The problem is that for some opcodes it's not clear *which* operand
> to use, e.g for 'in' you need to use the size of the source operand
> and ignore the one of the destination operand, while for 'out' it's
> just the opposite. Then again, there are some opcodes *without*
> operands, for which you do need to fall back to the default operand_size.
Most of those should have no suffix at all...
"clil" or "cliw" is ridiculous :)
> > I had a look at the objdump code,
> > they had in their instruction name table
> > separate names for, for instance,
> > addb and addw/l (which was called addS,
> > where the S was replaced by the correct
> > suffix later on).
>
> This is probably the best idea. You could have letters like 'S', 'D', ...
> where a 'S' is replaced by the size of the source operand (op[1].size),
> while 'D' is replaced by the size of the destination (op[0].size) etc.
>
> (Note that you don't need to have separate addb and addw/l, as the
> source operand size will be 1, 2, or 4 respectively, so just addS
> should work.)
That's going to be a LOT of work...
Can't I just copy the objdump code ?
Of course, THAT code doesn't support Intel :-/
-- Ramon
