search

mfld-fr / emu86

Intel IA16 emulator for embedded development
35 stars 6 forks source link

Minor fixes to AT&T display and ^S/^Q usage #8

Closed ghaerr closed 3 years ago

ghaerr commented 3 years ago

Fixes (%bx,%di) display. Restricts sign extension to word on display of signed negative offsets. Allows use of ^S/^Q during c)ontinue instruction tracing.

I'm not sure the instruction "FF 36 01 00" is being displayed properly: "PUSH 0x0001". Should that be "PUSH $0x0001"? Not sure how to fix this.

I'm also not sure how to test the proper display of instructions that need BYTE or WORD arguments:

"mov $0,0x40" - would that be a byte or word move of 0 to DS:0x40? Haven't seen this in the instruction stream.

Thinking of adding a way to change a memory location or register and then executing there to display an instruction, or can you think of an easier way to do this?

mfld-fr commented 3 years ago

@ghaerr : Thanks for the fixes !

For FF 36 01 00, this is PUSH WORD [0x0001] in Intel syntax, or PUSHW 0x0001 in AT&T syntax. PUSH imm is a 80186/80188 instruction (opcode 0x68).

What are the opcodes for the ambiguous mov $0,0x40 ?

ghaerr commented 3 years ago

@mfld-fr,

What are the opcodes for the ambiguous mov $0,0x40 ?

Here's an example of the byte and word versions for the above opcode. I don't think these are being displayed properly in EMU86, using my AT&T style printing changes. I'm looking for input as to where I can find the information as to when to display "movb" vs "movw" in the print_xxx routines. Currently, "mov" is always displayed for both.

test.s:
    movb    $0,0x1234
    movw    $0,0x1234
test.o:
   0:   c6 06 34 12 00          movb   $0x0,0x1234
   5:   c7 06 34 12 00 00       movw   $0x0,0x1234

I was hoping to use the intel printing code referencing outputting "WORD" and "BYTE" modifiers but that doesn't seem available during the print_xxx routines. I haven't yet changed the WORD/BYTE code from Intel printing yet, as I've only seen it output when parsing the SCAS instruction.

Of course, there are quite a few other versions of movb/movw required differentiation than just this opcode.

For FF 36 01 00, this is PUSH WORD [0x0001] in Intel syntax, or PUSHW 0x0001 in AT&T syntax. PUSH imm is a 80186/80188 instruction (opcode 0x68).

Thanks. I think the AT&T display for opcode FF 36 01 00 is working, it displays "PUSH 0x0001" for AT&T. I have not yet tested nor seen opcode 68 01 00 , which I think will display also properly as "PUSH $0x0100". We don't yet have an easy way to load or change memory in emu86 to test things like this. Or can the -w addr -f file option be used with any binary file? If so, a regression test for printing opcodes could be created and checked. I realize this is mostly low priority.

Thank you!

mfld-fr commented 3 years ago

@ghaerr : I agree EMU86 could be improved to be more explicit on the size of the operand. Today it gives a hint with the number of digits when printing an immediate (in op-print-* file, print_var function). Would be more explicit with 'B' or 'W' suffixes for AT&T syntax, or 'BYTE' and 'WORD' qualifiers for Intel syntax.

I think the best solution is to add a 'w' flag at the op-desc level, that would be uninitialized by default, and set in op-class upon dealing with any 'w' flag from the opcode. That way the print_op could append the suffix or the qualifier based on that 'w' flag in op-desc.

Opening a new issue to track this change request : #9

mfld-fr commented 3 years ago

@ghaerr : options -f and -w can be used with any binary file, except when using -p.