Not sure about linux, but this works on x86/windows. Update: http://codepad.org/sQoF6kR8 #include <stdio.h> #include <windows.h> typedef unsigned char byte; int arg1; int arg2; int res1; typedef void (*pfunc)(void); union funcptr { pfunc x; byte* y; }; int main( void ) { byte* buf = (byte*)VirtualAllocEx( GetCurrentProcess(), 0, 1<<16, MEM_COMMIT, PAGE_EXECUTE_READWRITE ); if( buf==0 ) return …
AMD and Intel processors(*) have a large set of instructions in common, so it is possible for a compiler or assembler to write binary code which runs “the same” on both. However, different processor families even from one manufacturer have their own sets of instructions, usually referred to as “extensions” or whatever. Ignoring the x87 …
Courtesy of William Chan and Google. 30-70% faster than memcpy in Microsoft Visual Studio 2005. void X_aligned_memcpy_sse2(void* dest, const void* src, const unsigned long size) { __asm { mov esi, src; //src pointer mov edi, dest; //dest pointer mov ebx, size; //ebx is our counter shr ebx, 7; //divide by 128 (8 * 128bit registers) …
volatile only forces your code to re-read the value, it cannot control where the value is read from. If the value was recently read by your code then it will probably be in cache, in which case volatile will force it to be re-read from cache, NOT from memory. There are not a lot of …
TL:DR: On every modern ISA that has byte-store instructions (including x86), they’re atomic and don’t disturb surrounding bytes. (I’m not aware of any older ISAs where byte-store instructions could “invent writes” to neighbouring bytes either.) The actual implementation mechanism (in non-x86 CPUs) is sometimes an internal RMW cycle to modify a whole word in a …
I’ve no idea why GCC organizes its stack the way it does (though I guess you could crack open its source or this paper and find out), but I can tell you how to guarantee the order of specific stack variables if for some reason you need to. Simply put them in a struct: void …
Ad 1. Those types are designed to work with numbers with huge dynamic range. The long double is implemented in a native way in the x87 FPU. The 128b double I suspect would be implemented in software mode on modern x86s, as there’s no hardware to do the computations in hardware. The funny thing is …
L1 is very tightly coupled to the CPU core, and is accessed on every memory access (very frequent). Thus, it needs to return the data really fast (usually within on clock cycle). Latency and throughput (bandwidth) are both performance-critical for L1 data cache. (e.g. four cycle latency, and supporting two reads and one write by …
I suggest also using -fverbose-asm because then the generated assembler has some generated comments which “explains” the code. For example: gcc -S -fverbose-asm -O2 foo.c would generate in foo.s (with some comments) the assembler code produced by compiling foo.c And to understand what the GCC optimizations are doing one could even try -fdump-tree-all (but this …
Yes, it’s safe in x86 asm, and existing libc strlen(3) implementations take advantage of this in hand-written asm. And even glibc’s fallback C, but it compiles without LTO so it it can never inline. It’s basically using C as a portable assembler to create machine code for one function, not as part of a larger …