Re: [PATCH] x86: fix disassembly of 16-bit fixed size mem ops

["Jan Beulich" <jbeulich at novell dot com>]

>>> "H. J. Lu" <hjl@lucon.org> 04.12.06 16:56 >>>
>On Mon, Dec 04, 2006 at 08:40:30AM +0000, Jan Beulich wrote:
>> >> The Intel disassembly version actually exposes a disassembler bug; I'll
>> >> commit it with a broken expectation for now until I get to fix this. The
>> >> problem is that on calls and jumps in Intel mode there's no defined way
>> >> to express an operand size override with the opcode or operand,
>> >> hence it gets a data16 prefix disassembled, but that obviously leads
>> >> to the immediate being treated as 32 bits wide when the actual opcode
>> >> then is being dealt with in the next step. I'm not sure how to actually
>> >> address this - use a suffix here, too? Use a 'small' operand modifier
>> >> like Borland's TASM does?
>> >
>> >How does Microsoft ASM handle it?  Can you open a bug report with
>> >a testcase? I'd like to track it.
>> 
>> They don't seem to permit this at all (after all, this is pretty useless - at
>>> least I can't imagine where it would make sense).
>> However, a quick test also shows that you *have* to use e.g. pushfd in
>> 32-bit mode (pushf assembles as 16-bit op, and there's no pushfw).
>> This all seems pretty ugly, so I'm not sure we want to be *this* close to
>> MASM.
>
>What does nasm do? If it isn't supported by those Intel mode
>assemblers, we can just pick something which works for gas. If gas
>doesn't support it either, we can pick anything as long as it won't
>assemble.

I never used nasm. gas supports 'd' and 'w' suffixes in Intel mode, but
with far more places where they might be used than there should be.
Not sure what you mean with 'we can pick anything as long as it won't
assemble' - the 'won't' in here isn't clear to me.

Jan