64-bit Assembly porting Summary (learning and learning)

Here, the transplantation mainly targets 64-bit CPUs from 32-bit x86cpu to Intel and AMD, as well as the xinxp64 platform. The compiling environment is vs 2005.netand mainly involves porting the assembly language. The compilation language compiler is yasm.

For the C language, you can directly compile the 64-bit platform in the vs2005.net environment. There are many articles to note, so we will not repeat them here.

A. for assembly languages, you must first note that they must be in the pure Assembly format (*. ASM file) or intrinsic Instruction format. Secondly, on the 64-bit platform, we do not recommend using the NASM Compiler (I did not find its support for 64-bit compilation). Instead, we recommend using yasm, this assembly compiler is generated on the basis of NASM, can be said to be compatible with the functions of NASM, and support 64-bit compilation, detailed introduction and relevant download see: http://www.tortall.net/projects/yasm/

B. The x86-64 has eight more general registers than the x86-32, and each general register is 64-bit wide and they are:
Rax, RBx, rcX, RDX, RSI, RDI, RSP, RBP
R8, R9, R10, R11, R12, R13, R14, R15
At the same time, the x86-64 fully supports General registers for x86-32 and x86-16:
Eax, ax, Al, ah,
EBX, BX, BL, BH,
However, when performing inbound/outbound stack operations on registers, the corresponding 64-bit registers can only be inbound/outbound, that is:
(Instructions that modify the stack (push, Pop, call, RET, enter, and leave) are implicitly 64-bit. their 32-bit counterparts are not available, but their 16-bit counterparts are. examples in NASM Syntax:
Push eax; illegal instruction
Push RBx; 1-byte instruction
Push R11; 2-byte instruction with Rex prefix)

C. x64 call conventions:

During the design of the call schedule, the x64 architecture uses the opportunity to clear the confusion of existing Win32 call conventions (such as _ stdcall, _ cdecl, _ fastcall, and _ thiscall. In win64, only one native call Convention and modifiers such as _ cdecl are ignored by the compiler. In addition, reducing the call conventions also brings debugging benefits.

The main content of the x64 call convention you need to know is: Its similarities with the x86 fastcall convention. In x64 conventions, the first four Integer Parameters (from left to right) are passed into the specified 64-bit register:

RCX: 1st integer argumentRDX: 2nd integer argumentR8: 3rd integer argumentR9: 4th integer argument

Integer Parameters other than the first four are passed to the stack. This pointer is regarded as an integer parameter, so it is always in the rcX register. For floating-point parameters, the first four parameters will be passed into the xmm0 to the xmm3 register, and subsequent floating-point parameters will be placed on the thread stack.

Further explore the call conventions. Even if a parameter can be passed into a register, the compiler can still reserve space for it by consuming the RSP register on the stack. At least, each function must reserve 32 bytes (4 64-bit values) on the stack ). This space allows you to easily copy registers of input functions to known stack locations. It is not required that the called function overflow the input register parameter to the stack, but when necessary, the stack space is reserved to ensure that it can do so. Of course, if you want to pass more than four Integer Parameters, you must reserve additional stack space.

Let's look at an example. Consider a function that passes two Integer Parameters to a subfunction. The compiler not only assigns the value to rcX and RDX, but also deducts 32 bytes from the RSP Stack pointer register. In the called function, parameters can be accessed in registers (rcX and RDX. If the called code requires registers for other purposes, you can copy the registers to the reserved 32-byte stack area. Figure 6 shows the registers and stacks after passing 6 integer parameters.

Figure 6 passing Integers

For the parameter pressure stack here, it must be noted that (for Integer Parameters ):
1. parameters after the fourth parameter are pushed to the stack in reverse order (8 bytes)
2. The 32 bytes reserved for the first four parameters occupy a fixed space and are pre-allocated. They are not the responsibility of the function caller. That is to say, whether you use them or not, this part of the stack space is occupied, and RSP points to the position shown in.
So for the above example, if the call function is important to access P5, the correct method of P6 is:
MoV eax, [esp + 32 + 8]; P5
MoV EBX, [esp + 32 + 16]; p6

D. A very special register rip, which is equivalent to the eip of the x86-32. in the x86-32 is not directly accessible, such as mov eax, EIP is wrong, but in the x86-64 bit but can, such as mov, rax, qword PTR [RIP + 100] is correct. Besides a program counter, it is also a "Data Base Address". It can be seen that it is now in two roles! Why use RIP as the base address for data access in the x86-64 bit? Because, in the x86-64, DS, es, Cs, SS have no practical significance, that is, they are no longer involved in address computing, just to be compatible with the x86-32. FS, Gs is still involved in address computing, and both of them have the same meaning as the x86-32. Because ds, es, Cs, and SS are meaningless, symbol variables are not allowed to appear directly in assembly code during dynamic library compilation, but must be used together with Rip, that is
MoV rax, [symb WRT Rip] or Lea RBx, [symb WRT Rip]

Reference webpage:
Amd64 Architecture --- http://www.tortall.net/projects/yasm/wiki/AMD64
All the information you need to know before you start programming 64-bit windows-http://www.microsoft.com/china/MSDN/library/Windev/64bit/issuesx64.mspx? MFR = true
The history of calling conventions, Part 5: amd64 --- http://blogs.msdn.com/oldnewthing/archive/2004/01/14/58579.aspx

Here, the transplantation mainly targets 64-bit CPUs from 32-bit x86cpu to Intel and AMD, as well as the xinxp64 platform. The compiling environment is vs 2005.netand mainly involves porting the assembly language. The compilation language compiler is yasm.

For the C language, you can directly compile the 64-bit platform in the vs2005.net environment. There are many articles to note, so we will not repeat them here.

A. for assembly languages, you must first note that they must be in the pure Assembly format (*. ASM file) or intrinsic Instruction format. Secondly, on the 64-bit platform, we do not recommend using the NASM Compiler (I did not find its support for 64-bit compilation). Instead, we recommend using yasm, this assembly compiler is generated on the basis of NASM, can be said to be compatible with the functions of NASM, and support 64-bit compilation, detailed introduction and relevant download see: http://www.tortall.net/projects/yasm/

B. The x86-64 has eight more general registers than the x86-32, and each general register is 64-bit wide and they are:
Rax, RBx, rcX, RDX, RSI, RDI, RSP, RBP
R8, R9, R10, R11, R12, R13, R14, R15
At the same time, the x86-64 fully supports General registers for x86-32 and x86-16:
Eax, ax, Al, ah,
EBX, BX, BL, BH,
However, when performing inbound/outbound stack operations on registers, the corresponding 64-bit registers can only be inbound/outbound, that is:
(Instructions that modify the stack (push, Pop, call, RET, enter, and leave) are implicitly 64-bit. their 32-bit counterparts are not available, but their 16-bit counterparts are. examples in NASM Syntax:
Push eax; illegal instruction
Push RBx; 1-byte instruction
Push R11; 2-byte instruction with Rex prefix)

C. x64 call conventions:

During the design of the call schedule, the x64 architecture uses the opportunity to clear the confusion of existing Win32 call conventions (such as _ stdcall, _ cdecl, _ fastcall, and _ thiscall. In win64, only one native call Convention and modifiers such as _ cdecl are ignored by the compiler. In addition, reducing the call conventions also brings debugging benefits.

The main content of the x64 call convention you need to know is: Its similarities with the x86 fastcall convention. In x64 conventions, the first four Integer Parameters (from left to right) are passed into the specified 64-bit register:

RCX: 1st integer argumentRDX: 2nd integer argumentR8: 3rd integer argumentR9: 4th integer argument

Integer Parameters other than the first four are passed to the stack. This pointer is regarded as an integer parameter, so it is always in the rcX register. For floating-point parameters, the first four parameters will be passed into the xmm0 to the xmm3 register, and subsequent floating-point parameters will be placed on the thread stack.

Further explore the call conventions. Even if a parameter can be passed into a register, the compiler can still reserve space for it by consuming the RSP register on the stack. At least, each function must reserve 32 bytes (4 64-bit values) on the stack ). This space allows you to easily copy registers of input functions to known stack locations. It is not required that the called function overflow the input register parameter to the stack, but when necessary, the stack space is reserved to ensure that it can do so. Of course, if you want to pass more than four Integer Parameters, you must reserve additional stack space.

Let's look at an example. Consider a function that passes two Integer Parameters to a subfunction. The compiler not only assigns the value to rcX and RDX, but also deducts 32 bytes from the RSP Stack pointer register. In the called function, parameters can be accessed in registers (rcX and RDX. If the called code requires registers for other purposes, you can copy the registers to the reserved 32-byte stack area. Figure 6 shows the registers and stacks after passing 6 integer parameters.

Figure 6 passing Integers

For the parameter pressure stack here, it must be noted that (for Integer Parameters ):
1. parameters after the fourth parameter are pushed to the stack in reverse order (8 bytes)
2. The 32 bytes reserved for the first four parameters occupy a fixed space and are pre-allocated. They are not the responsibility of the function caller. That is to say, whether you use them or not, this part of the stack space is occupied, and RSP points to the position shown in.
So for the above example, if the call function is important to access P5, the correct method of P6 is:
MoV eax, [esp + 32 + 8]; P5
MoV EBX, [esp + 32 + 16]; p6

D. A very special register rip, which is equivalent to the eip of the x86-32. in the x86-32 is not directly accessible, such as mov eax, EIP is wrong, but in the x86-64 bit but can, such as mov, rax, qword PTR [RIP + 100] is correct. Besides a program counter, it is also a "Data Base Address". It can be seen that it is now in two roles! Why use RIP as the base address for data access in the x86-64 bit? Because, in the x86-64, DS, es, Cs, SS have no practical significance, that is, they are no longer involved in address computing, just to be compatible with the x86-32. FS, Gs is still involved in address computing, and both of them have the same meaning as the x86-32. Because ds, es, Cs, and SS are meaningless, symbol variables are not allowed to appear directly in assembly code during dynamic library compilation, but must be used together with Rip, that is
MoV rax, [symb WRT Rip] or Lea RBx, [symb WRT Rip]

Reference webpage:
Amd64 Architecture --- http://www.tortall.net/projects/yasm/wiki/AMD64
All the information you need to know before you start programming 64-bit windows-http://www.microsoft.com/china/MSDN/library/Windev/64bit/issuesx64.mspx? MFR = true
The history of calling conventions, Part 5: amd64 --- http://blogs.msdn.com/oldnewthing/archive/2004/01/14/58579.aspx