NASM differs from the MASM of VS, such as the NASM source program can have only instructions, without the need for segment distribution, main functions and so on. Here is an example:
mov eax, 0
inc eax
Compile with NASM:
A test.bin is generated when the compilation is complete:
Open this test.bin to see the machine code of the instruction:
The disassembly of the corresponding source code in VS:
A 66 More, what do you mean .
To modify the NASM compiler source program:
The resulting machine code programming:
There is still a problem, different machine code, how to run inside the same x86cpu .
-----------------------------------------------------
(Updated 2016.08.21)
66 is the instruction prefixes in the Intel assembler, which is the instruction prefix. There are several instruction prefix types, 66 of which belong to the Oprand-size override prefix.
Intel does not intentionally use different machine codes for different operands under the same instruction, but rather to differentiate them by prefixes. This can explain the difference between the two MOV instructions above NASM.
However, vs and nasm have different results under the same 32-bit operand and are not able to explain.
(Updated 2017.01.02)
The compiled host used here is 64 bits, and the default system is not specified in the code above, so it uses a 64-bit compilation, so in order to get consistent results with VS disassembly, you need to set the number of system bits at compile time:
Bits
of mov eax, 0
inc eax
The results of this compilation are as follows:
-----------------------------------------------------
The above Test.bin theoretically the CPU can be directly executed, but in the Windows system is not aware of the other, in order to solve this problem, you can use the virtual machine, the bin file directly to the end of the virtual machine to jump to the location (0X7C00, is actually the first sector of the hard disk is loaded location), This allows the bin file to be executed directly. So all we have to do is change the first sector used by the virtual machine to the bin we need, and we can execute the code.
Here is the NASM source code for HelloWorld:
mov ax, 0xb800; Indicates the starting position of the video memory (also mentioned later)
mov ds, ax
mov byte [0x00], ' H '; print Hello world!
mov byte [0x01],0x07
mov byte [0x02], ' e '
mov byte [0x01],0x07
mov byte [0x04], ' l '
mov byte [0x01],0x07
mov byte [0x06], ' l '
mov byte [0x01],0x07
mov byte [0x08], ' o '
mov byte [0x01],0x07
mov byte [0x0C], ' W '
mov byte [0x01],0x07
mov byte [0x0E], ' o '
mov byte [0x01],0x07
mov byte [0x10], ' R '
mov byte [0x01],0x07
mov byte [0x12], ' l '
mov byte [0x01],0x07
mov byte [0x14], ' d '
mov byte [0x01],0x07
mov byte [0x16], '! '
mov byte [0x01],0x07
JMP $; Let the CPU hang here Times
393 db 0
db 0x55, 0XAA; virtual machines need to detect MBR tags
After compiling, get the binary, and write the binary to the hard disk used by the virtual machine, as shown in the figure:
Ps:
The example of running binary using virtual machines comes from the x86 assembly language: From actual mode to protected mode.