972
edits
Babystep3: Difference between revisions
m
Bot: Replace deprecated source tag with syntaxhighlight
| [unchecked revision] | [unchecked revision] |
No edit summary |
m (Bot: Replace deprecated source tag with syntaxhighlight) |
||
| (2 intermediate revisions by 2 users not shown) | |||
Line 9:
=== A look at machine code (opcodes, prefix, etc) ===
; nasmw encode.asm -f bin -o encode.bin▼
<
mov cx, 0xFF
times 510-($-$$) db 0
db 0x55
db 0xAA
</syntaxhighlight>
Don't partycopy to disk. Just open this in DEBUG (for Windows, Hexdump will be nice for Linux users)
Line 32 ⟶ 33:
But watch what happens when you replace CX with ECX:
<
mov ecx, 0xFF
times 510-($-$$) db 0
db 0x55
db 0xAA
</syntaxhighlight>
0AE3:0100 66 B9 FF 00 00 00 00 etc...
The '66' is an Operand Size Override Prefix generated by the assembler when there is a discrepancy with the default mode, which when NASM assembles binary files, it is 16-bit. The same thing happens if you use the BITS directive to change the mode, but it differs from the size of the operand:
<
[BITS 32]
mov cx, 0xFF
Line 48 ⟶ 49:
db 0x55
db 0xAA
</syntaxhighlight>
This doesn't actually change the mode of the processor, but it does help it interpret the subsequent bytes.
Line 56 ⟶ 57:
Address encoding is a bit more complicated
<
mov cx, [temp]
Line 63 ⟶ 64:
db 0x55
db 0xAA
</syntaxhighlight>
0AE3:0100 8B 0E 04 00 99 00 00 00 etc...
Line 72 ⟶ 73:
See Section "17.2.1 ModR/M and SIB Bytes" here: [http://www.baldwin.cx/386htm/s17_02.htm http://www.baldwin.cx/386htm/s17_02.htm]
The rules for interpreting this byte are complicated,
'04 00' is the 16-bit offset. If you are confused why 0x0004 is backwards, it's because the Intel processor is "little endian". The "little" end of the number comes first.
| |||