assembly

问题 This question already has answers here : Does a compiler always produce an assembly code? (4 answers) What do C and Assembler actually compile to? [closed] (12 answers) Closed 20 days ago . I have started learning C++, and I have learned that a compiler turns source code from a program into machine code through compilation. However, I've learned that C++ compilers actually translate the source code into Assembly as an interim step before translating the Assembly code into machine code. What

问题 This question already has answers here : Does a compiler always produce an assembly code? (4 answers) What do C and Assembler actually compile to? [closed] (12 answers) Closed 20 days ago . I have started learning C++, and I have learned that a compiler turns source code from a program into machine code through compilation. However, I've learned that C++ compilers actually translate the source code into Assembly as an interim step before translating the Assembly code into machine code. What

问题 xor dword [0x301a80], 0x12345 How many memory access when we know the op code and addressing mode is 2 bytes? If I understand correctly, even thought it is 0x12345, this is acctually still 4 bytes and we cant attach it to 0x301a80, right? So we have here: 2 + 4 + 4 bytes (And not 2 + 3.5 + 2.5 = 8) which is 4 memory access. Am I think right? 回答1: The total instruction size is 10 bytes (in 32-bit mode). That takes probably 0 to 2 I-cache accesses on a modern x86 to fetch in aligned 16-byte

问题 A prior related question was answered. Thank you! However this creates a new question for me. Why does nasm put data bytes at two different memory locations? I include program information and other data dump below. ---------- code snippet compiled with nasm, ld ----------------- section .text ... zero: jmp short two one: pop ebx xor eax, eax mov [ebx+12], eax mov [ebx+8], ebx mov [ebx+7], al lea ecx, [ebx+8] lea edx, [ebx+12] mov al, 11 int 0x80 two: call one section .data align=1 msg: db '

问题 A prior related question was answered. Thank you! However this creates a new question for me. Why does nasm put data bytes at two different memory locations? I include program information and other data dump below. ---------- code snippet compiled with nasm, ld ----------------- section .text ... zero: jmp short two one: pop ebx xor eax, eax mov [ebx+12], eax mov [ebx+8], ebx mov [ebx+7], al lea ecx, [ebx+8] lea edx, [ebx+12] mov al, 11 int 0x80 two: call one section .data align=1 msg: db '

问题 There's only 1 circumstance where __builtin_clz gives the wrong answer. I'm curious what's causing that behavior. When I use the literal value 0 I always get 32 as expected. But 0 as a variable yields 31. Why does the method of storing the value 0 matter? I've taken an architecture class but don't understand the diffed assembly. It looks like when given the literal value 0, the assembly somehow always has the correct answer of 32 hard coded even without optimizations. And the method for

问题 My question arises from a simple curiosity: Why in x64 some of the opcodes are invalid (06, 07 for example), whereas in x86 are used for fairly basic instructions (06 and 07 being push and pop)? I though that those simplest instructions would do nicely in both architectures. Why they disabled some of those simple instructions in x64? Why wouldn't they work? Why they disabled some opcodes, creating holes in opcode list, when they could instead assign them to x64 versions of instructions?

问题 I have the following code snippet: #include <inttypes.h> #include <stdio.h> uint64_t esp_func(void) { __asm__("movl %esp, %eax"); } int main() { uint32_t esp = 0; __asm__("\t movl %%esp,%0" : "=r"(esp)); printf("esp: 0x%08x\n", esp); printf("esp: 0x%08lx\n", esp_func()); return 0; } Which prints the following upon multiple executions: ❯ clang -g esp.c && ./a.out esp: 0xbd3b7670 esp: 0x7f8c1c2c5140 ❯ clang -g esp.c && ./a.out esp: 0x403c9040 esp: 0x7f9ee8bd8140 ❯ clang -g esp.c && ./a.out esp:

问题 Hullo, I am learning x86 FPU assembly, and I have got a simple question I cannot find answer for: How to move value from ST(0) ( top of the FPU stack ) to EAX ? also: is this code correct: ; multiply (dot) two vectors of 3 floats passed by pointers as arg 1 arg 2 ; passings are ok I think, but not sure if multiplies-adds are ok push ebp mov ebp, esp mov eax, dword [ebp+8H] mov edx, dword [ebp+0CH] fld qword [eax] fmul qword [edx] fld qword [eax+4H] fmul qword [edx+4H] fld qword [eax+8H] fmul

问题 I am trying to write directly to a physical memory location, so I am using an assembly function to first disable paging, write the value, and then re-enable paging, but for some reason a page fault is still triggered when trying to write the value. As I understand it, in x86-32bit, paging is set on and off by flipping bit 32 in cr0, so here is my assembly function: mov 4(%esp), %ecx //address mov 8(%esp), %edx //value mov %cr0, %eax and $0x7fffffff, %eax mov %eax, %cr0 mov %edx, (%ecx) //this