x86-64

问题 I am interested in executing a function which is written in C language:- //filename "CLang.c" #include<stdio.h> void fun() { printf("Hello World"); } I want to call this fun() through assembly language which i have written:- (NASM 64bit) ; filename "MyASM.asm" section .data section .bss section .text global _start _start: call fun mov rax,60 ; exit mov rdi,1 syscall I have created object file by using these commands nasm -f elf64 MyAsm.asm and gcc -c CLang.c . When I merge these two file with

问题 I am interested in executing a function which is written in C language:- //filename "CLang.c" #include<stdio.h> void fun() { printf("Hello World"); } I want to call this fun() through assembly language which i have written:- (NASM 64bit) ; filename "MyASM.asm" section .data section .bss section .text global _start _start: call fun mov rax,60 ; exit mov rdi,1 syscall I have created object file by using these commands nasm -f elf64 MyAsm.asm and gcc -c CLang.c . When I merge these two file with

问题 This question already has answers here : What registers are preserved through a linux x86-64 function call (3 answers) Closed 6 months ago . can anyone explain why this code snippet goes into an infinite loop? I presume it would have something to do with the printf function. q1: .asciz "Hello World\n" .global main main: movq %rsp, %rbp movq $3, %rcx jmp bottom loop: movq $0, %rax movq $q1, %rdi call printf bottom: decq %rcx cmpq $0, %rcx jne loop end: movq $0, %rdi call exit 回答1: The only

问题 Whats the difference between using the built-in call and return instructions vs manually pushing and popping the stack and using jumps for functions? 回答1: Functionally, if you do it correctly, nothing. However it takes more instructions and/or registers to emulate call / ret using push / pop . Of course if you really wanted to take it to the extreme, you could also emulate push / pop using lea and mov :) Also, current processors have specialized hardware to handle function calls for the

问题 Most architectures have different set of registers for storing regular integers and floating points. From a binary storage point of view, it shouldn't matter where things are stored right? it's just 1's and 0's, couldn't they pipe the same general purpose registers into floating point ALUs? SIMD ( xmm in x64) registers are capable of storing both Floating point and regular integers, so why doesn't the same concept apply to regular registers? 回答1: For practical processor design, there are a

问题 I am reading Agner Fog's book on x86 assembly. I am wondering about how RIP-relative addressing works in this scenario. Specifically, assume my RIP offset is +1. This suggests the data I want to read is right next to this instruction in memory. This piece of data is likely already fetched into the L1 instruction cache. Assuming that this data is not also in the L1d, what exactly will happen on the CPU? Let's assume it's a relatively recent Intel architecture like Kaby Lake. 回答1: Yes, it's

问题 I am reading Agner Fog's book on x86 assembly. I am wondering about how RIP-relative addressing works in this scenario. Specifically, assume my RIP offset is +1. This suggests the data I want to read is right next to this instruction in memory. This piece of data is likely already fetched into the L1 instruction cache. Assuming that this data is not also in the L1d, what exactly will happen on the CPU? Let's assume it's a relatively recent Intel architecture like Kaby Lake. 回答1: Yes, it's

问题 Let's say I have a nasm function like this: inc: mov rax,[rsp + 8] add [rax],BYTE 1 ret And I am calling this function like this: push some_var call inc I want to pass an argument to the function through the stack, so I push some_var and then call my function. In the function my item is second on the stack so I take it like: mov rax,[rsp+8] My question is: after calling function should I somehow pop my argument from the stack? If so, can I somehow delete it from the stack, I mean pop it, but

问题 Are there any guidelines in x86-64 for when a function should abide by the System V guidelines and when it doesn't matter? This is in response to an answer here which mentions using other calling conventions for simplifying an internal/local function. # gcc 32-bit regparm calling convention is_even: # input in RAX, bool return value in AL not %eax # 2 bytes and $1, %al # 2 bytes ret # custom calling convention: is_even: # input in RDI # returns in ZF. ZF=1 means even test $1, %dil # 4 bytes.

问题 We are running some code in both VisualStudio process context (x86 context) and out of VisualStudio context (x64 context). I notice the following code provides a different result in both context (100000000000 in x86 and 99999997952 in x64) float val = 1000f; val = val * val; return (ulong)(val * 100000.0f); We need to obtain a ulong value from a float value in a reliable way, no matter the context and no matter the ulong value, it is just for hashing purpose. I tested this code in both x64