x86-64

SSE instruction MOVSD (extended: floating point scalar & vector operations on x86, x86-64)

六月ゝ 毕业季﹏ 提交于 2019-11-28 06:11:00
问题 I am somehow confused by the MOVSD assembly instruction. I wrote some numerical code computing some matrix multiplication, simply using ordinary C code with no SSE intrinsics. I do not even include the header file for SSE2 intrinsics for compilation. But when I check the assembler output, I see that: 1) 128-bit vector registers XMM are used; 2) SSE2 instruction MOVSD is invoked. I understand that MOVSD essentially operates on single double precision floating point. It only uses the lower 64

GCC: putchar(char) in inline assembly

*爱你&永不变心* 提交于 2019-11-28 05:55:08
问题 Overflow, how can I implement the putchar(char) procedure using inline assembly only? I would like to do this in x86-64 assembly. The reason for me doing this is to implement my own standard-lib (or at least part of it). Here is what I have so far: void putchar(char c) { /* your code here: print character c on stdout */ asm(...); } void _start() { /* exit system call */ asm("mov $1,%rax;" "xor %rbx,%rbx;" "int $0x80" ); } I am compiling with: gcc -nostdlib -o putchar putchar.c Thanks for

Difference in position-independent code: x86 vs x86-64

谁都会走 提交于 2019-11-28 05:51:59
I was recently building a certain shared library (ELF) targeting x86-64 architecture, like this: g++ -o binary.so -shared --no-undefined ... -lfoo -lbar This failed with the following error: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC Of course, it means I need to rebuild it as position-independent code, so it's suitable for linking into a shared library. But this works perfectly well on x86 with exactly the same build arguments. So the question is, how is relocation on x86 different from x86-64 and why don't I need to

Why is the construction of std::optional<int> more expensive than a std::pair<int, bool>?

佐手、 提交于 2019-11-28 05:36:55
Consider these two approaches that can represent an "optional int ": using std_optional_int = std::optional<int>; using my_optional_int = std::pair<int, bool>; Given these two functions... auto get_std_optional_int() -> std_optional_int { return {42}; } auto get_my_optional() -> my_optional_int { return {42, true}; } ...both g++ trunk and clang++ trunk (with -std=c++17 -Ofast -fno-exceptions -fno-rtti ) produce the following assembly: get_std_optional_int(): mov rax, rdi mov DWORD PTR [rdi], 42 mov BYTE PTR [rdi+4], 1 ret get_my_optional(): movabs rax, 4294967338 // == 0x 0000 0001 0000 002a

Is there any type checking in C or C++ linkers?

孤街浪徒 提交于 2019-11-28 05:19:19
问题 Am I right in saying linkers make no function parameter checks. They do not check the number or types of function calls nor do they check the type of global data references. Is this true for all linkers? I'm using Clang targeting Linux on x86-64. Does the linker check that references are in the right segment? Or is an external reference in effect just a void * as far as the linker is concerned? I'm coming from a high level language background C# and Scala, so this may seem obvious to those

Memory access error sys_rt_sigaction (signal handler)

人走茶凉 提交于 2019-11-28 05:00:04
问题 Following this Interfacing Linux Signals article, i have been trying to use sys_rt_sigaction in amd64 , but always get memory access error when sending the signal. struct sigaction works when using C/C++ function sigaction . What is wrong in sys_rt_sigaction call? C/C++ with ASM code: #include<signal.h> #include<stdio.h> #include<time.h> void handler(int){printf("handler\n");} void restorer(){asm volatile("mov $15,%%rax\nsyscall":::"rax");} struct sigaction act{handler}; timespec ts{10,0};

Relative Addressing errors - Mac 10.10

寵の児 提交于 2019-11-28 04:50:04
问题 I'm trying to learn how to write assembly code and I'm doing it with the help of http://gnu.mirrors.pair.com/savannah/savannah//pgubook/ProgrammingGroundUp-0-8.pdf. It's an excellent resource and I'm trying to write the code as 64bit for my Mac in Macho64 format. I've run into some trouble with absolute and relative addressing. This is my code: DEFAULT REL ;PURPOSE: This program finds the maximum number of a set of data items ; ;VARIABLES: The registers have the following uses ; ; rbx - Holds

external assembly file in visual studio

百般思念 提交于 2019-11-28 04:35:17
I searched and found I can not use __asm in x64 in visual studio. Instead I have to use an external assembly file. How can I add external assembly file to my win32 console project? How can compile them? Can you explain step by step. How to build a mixed-source x64-project with a x64 assembly file in Visual Studio : 1) Start Visual Studio (Community) 2015 and choose FILE - New - Project . 2) In the next window choose Win 32 Console Application . 3) You get a confirmation. Click on Next > . 4) In the next window you can accept the default settings. Click on Finish . 5) Now choose PROJECT - Build

Advice for learning Linux x86-64 assembly & documentation [closed]

邮差的信 提交于 2019-11-28 04:34:18
Does anyone have documentation pertaining to learning the fundamentals of Linux x86-64 assembly? I'm not sure whether or not to learn it as is, or to learn x86 first, and learn it later, but being as I have an x86-64 computer and not an x86, I was thinking of learning x86-64 instead ;) Maybe someone could give me some incentive, and direction as to learning what, how, and with what documentation. Kindly give me your most favoured documentation titles, I code a little Python, this is my first attempt at a lower level language, and I'm more than ready to dedicate to it. Thanks all Callum General

Is it possible to use both 64 bit and 32 bit instructions in the same executable in 64 bit Linux?

纵然是瞬间 提交于 2019-11-28 04:31:58
问题 A 64 bit CPU (amd64) supports 32 bit Intel instructions in the compatibility mode. Also, a 64 bit Linux installation allows running ELFs containing 32 bit instructions if the ELF header says it is a 32 bit executable. I was wondering if it is possible to put some assembly instructions inside the ELF which switches the CPU to 32 bit compatibility mode in the middle of a program (and then later back again)? If these assembly instructions are not permitted by the kernel, is there perhaps some