baby steps #3 - encoding
Posted: Sun May 19, 2002 11:05 pm
<I've lost two posts already, so this is going to be sketchy>
;---------------------------------
; nasmw encode.asm -f bin -o encode.bin
???mov cx, 0xFF
???
???times 512-($-$$) db 0
;---------------------------------
Don't Partcopy to disk. Just open this in DEBUG (anyone know a Unix counterpart?)
C:\osdev\debug encode.bin
Type in 'd' after the '-' to see the binary file. ('?' will give you help; 'q' will quit). You will see something like this:
OAE3:0100 B9 FF 00 00 00 00 etc...
Look up the opcode for MOV here:
http://www.baldwin.cx/386htm/MOV.htm
See Section "17.2.2.1 Opcode" here:
http://www.baldwin.cx/386htm/s17_02.htm
In other words, there is a unique register number (CX=1) added to the base opcode value 'B8' to give 'B9', which you see in the dump.
But watch what happends when you replace CX with ECX:
;---------------------------------
???mov ecx, 0xFF
???
???times 512-($-$$) db 0
;---------------------------------
OAE3:0100 66 B9 FF 00 00 00 00 etc...
The '66' is a 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
???
???times 512-($-$$) db 0
;---------------------------------
This doesn't actually change the mode of the processor, but it does help it interpret the subsequent bytes.
???*************************
???
Address encoding is a bit more complicated
;---------------------------------
???mov cx, [temp]
temp db 0x99
???
???times 512-($-$$) db 0
;---------------------------------
OAE3:0100 8B 0E 04 00 99 00 00 00 etc...
'8B' is the opcode
'0E' is a ModR/M byte which helps the opcode interpret
See Section "17.2.1 ModR/M and SIB Bytes" here:
http://www.baldwin.cx/386htm/s17_02.htm
The rules for interpreting this byte, which contains different fields (see Fig. 17-2), but fortunately Table 17-2 makes it easier. Look up '0E' and you will see at the left it says "disp16" which means that the operand will be interpreted as a 16-bit offset.
'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.
'99' is of course the value of the byte at 0x0004 (8B is at 0x0000)
???*************************
???
Be aware of another prefix called the Address size Override Prefix '67' which the assembler generates when there is a discrepancy just like with '66' above.
???*************************
This stuff matters for a bunch of reasons, but since we will be making the switch from 16-bit real mode to 32-bit protected mode, our code is going to also change. And being aware of what a dump looks like can prevent a lot of grief.
Refs:
*** 0x86 guide
http://www.baldwin.cx/386htm/toc.htm
*** Nasm docs for download
http://sourceforge.net/project/showfile ... up_id=6208
*** DEBUG help
http://www.sju.edu/~yang/nasm/debughelp.htm
http://www.plumb.org/tekmage/Inspire/debug-manual.html
http://www.datainstitute.com/debug1.htm
;---------------------------------
; nasmw encode.asm -f bin -o encode.bin
???mov cx, 0xFF
???
???times 512-($-$$) db 0
;---------------------------------
Don't Partcopy to disk. Just open this in DEBUG (anyone know a Unix counterpart?)
C:\osdev\debug encode.bin
Type in 'd' after the '-' to see the binary file. ('?' will give you help; 'q' will quit). You will see something like this:
OAE3:0100 B9 FF 00 00 00 00 etc...
Look up the opcode for MOV here:
http://www.baldwin.cx/386htm/MOV.htm
See Section "17.2.2.1 Opcode" here:
http://www.baldwin.cx/386htm/s17_02.htm
In other words, there is a unique register number (CX=1) added to the base opcode value 'B8' to give 'B9', which you see in the dump.
But watch what happends when you replace CX with ECX:
;---------------------------------
???mov ecx, 0xFF
???
???times 512-($-$$) db 0
;---------------------------------
OAE3:0100 66 B9 FF 00 00 00 00 etc...
The '66' is a 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
???
???times 512-($-$$) db 0
;---------------------------------
This doesn't actually change the mode of the processor, but it does help it interpret the subsequent bytes.
???*************************
???
Address encoding is a bit more complicated
;---------------------------------
???mov cx, [temp]
temp db 0x99
???
???times 512-($-$$) db 0
;---------------------------------
OAE3:0100 8B 0E 04 00 99 00 00 00 etc...
'8B' is the opcode
'0E' is a ModR/M byte which helps the opcode interpret
See Section "17.2.1 ModR/M and SIB Bytes" here:
http://www.baldwin.cx/386htm/s17_02.htm
The rules for interpreting this byte, which contains different fields (see Fig. 17-2), but fortunately Table 17-2 makes it easier. Look up '0E' and you will see at the left it says "disp16" which means that the operand will be interpreted as a 16-bit offset.
'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.
'99' is of course the value of the byte at 0x0004 (8B is at 0x0000)
???*************************
???
Be aware of another prefix called the Address size Override Prefix '67' which the assembler generates when there is a discrepancy just like with '66' above.
???*************************
This stuff matters for a bunch of reasons, but since we will be making the switch from 16-bit real mode to 32-bit protected mode, our code is going to also change. And being aware of what a dump looks like can prevent a lot of grief.
Refs:
*** 0x86 guide
http://www.baldwin.cx/386htm/toc.htm
*** Nasm docs for download
http://sourceforge.net/project/showfile ... up_id=6208
*** DEBUG help
http://www.sju.edu/~yang/nasm/debughelp.htm
http://www.plumb.org/tekmage/Inspire/debug-manual.html
http://www.datainstitute.com/debug1.htm
03FF in the currently opened file in the Binary Editor and save it. Then I use the command "dd if=filename of=/dev/fd0" to write the file to the floppy (raw write as you windozers put it). Stick the floppy in and reboot and you're off! Not an easy task, but it is trivial now after a certain amount of time.
