assembly

问题 Does anyone have an idea how to get the current working directory in OSX with NASM? The syscall getcwd isn't available on osx and dtruss pwd return lots of stat sys calls. However in the manual I can't find which structure variable of stat returns the current working directory. Thanks. 回答1: That's a bit late answer, but nonetheless this can be achieved using 2 syscalls. open_nocancel 0x2000018e (or open 0x2000005) opening a file descriptor for current dir fcntl_nocancel 0x20000196 (or fcntl

问题 I have cross-compiled a 32-bit analog clock made in ArithmeticExpressionCompiler from Linux to DOS using the GNU Assembler. When run under FreeDOS in QEMU or VirtualBox (which are far better emulators than NTVDM is, right?), it creates this picture: I expected it to also run on Windows 10. However, when I try to run it on Windows 10, I get this error: What does that even mean? My program is not 16-bit, it's 32-bit, so why is some 16-bit subsystem even being run? And what does the "error 4001h

问题 This question already has answers here : Using printf in assembly leads to an empty ouput (2 answers) Can ptrace tell if an x86 system call used the 64-bit or 32-bit ABI? (1 answer) What happens if you use the 32-bit int 0x80 Linux ABI in 64-bit code? (1 answer) Closed 7 days ago . I'm trying to write a Python script to test the output of some various code I've written in assembly against an expected output. However I am having difficulty redirecting the output into a file. I have written the

问题 Intel pushed microcode update to fix error called "Jump Conditional Code (JCC) Erratum". The update microcode caused some operation to be inefficient due to disabling putting code to ICache under certain conditions. Published document, titled Mitigations for Jump Conditional Code Erratum lists not only JCC , it lists: unconditional jumps, conditional jumps, macro-fused conditional jumps, calls, and return. MSVC switch /QIntel-jcc-erratum documentation mentions: Under /QIntel-jcc-erratum, the

问题 First, I found this question: How do I atomically read a value in x86 ASM? But its a bit different, in my case I want to atomically assign a float (64bit double) value in a 32bit application. From: "Intel® 64 and IA-32 ArchitecturesSoftware Developer’s Manual, Volume3A" The Pentium processor (and newer processors since) guarantees that the following additional memory operations will always be carried out atomically: Reading or writing a quadword aligned on a 64-bit boundary Is it actually

问题 The following code is from include/asm-i386/io.h , and it is invoked from dma_map_single() . My understanding is that flush_write_buffers() is supposed to flush CPU memory cache before mapping the memory for DMA. But how does this assembly code flush CPU cache? static inline void flush_write_buffers(void) { __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory"); } 回答1: The Intel Pentium Pro processors had a bug wherein a store to a memory location of type UC may be reordered with

问题 I'm running a Core i7 3930k, which is of the Sandy Bridge microarchitecture. When executing the following code (compiled under MSVC19, VS2015), the results surprised me (see in comments): int wmain(int argc, wchar_t* argv[]) { uint64_t r = 0b1110'0000'0000'0000ULL; uint64_t tzcnt = _tzcnt_u64(r); cout << tzcnt << endl; // prints 13 int info[4]{}; __cpuidex(info, 7, 0); int ebx = info[1]; cout << bitset<32>(ebx) << endl; // prints 32 zeros (including the bmi1 bit) return 0; } Disassembly shows

问题 I noticed that calculating the integer part of square root of uint64_t is much more complicated than of int64_t . Please, does anybody have an explanation for this? Why is it seemingly much more difficult to deal with one extra bit? The following: int64_t sqrt_int(int64_t a) { return sqrt(a); } compiles with clang 5.0 and -mfpmath=sse -msse3 -Wall -O3 to sqrt_int(long): # @sqrt_int(long) cvtsi2sd xmm0, rdi sqrtsd xmm0, xmm0 cvttsd2si rax, xmm0 ret But the following: uint64_t sqrt_int(uint64_t

问题 I noticed that calculating the integer part of square root of uint64_t is much more complicated than of int64_t . Please, does anybody have an explanation for this? Why is it seemingly much more difficult to deal with one extra bit? The following: int64_t sqrt_int(int64_t a) { return sqrt(a); } compiles with clang 5.0 and -mfpmath=sse -msse3 -Wall -O3 to sqrt_int(long): # @sqrt_int(long) cvtsi2sd xmm0, rdi sqrtsd xmm0, xmm0 cvttsd2si rax, xmm0 ret But the following: uint64_t sqrt_int(uint64_t

问题 I have found this GAS file that contains some bootloader code that can boot off of a CD and I would like to study it and try and make one of my own but the only problem is that it is in AT&T syntax not in Intel syntax and I know nothing about AT&T syntax, I have tried to use Intel2gas converter but it didn't convert it fully and then I tried to convert what it couldn't and the program turned out to be a mess. Here is the Code that intel2gas output plus what I tried to fix: ;/* ISO-9660 boot