I've just started learning assembly yesterday, and the first useful thing I've written is a clearmem function.I'm looking for general feedback regarding my coding of this function, whether there any flaws with it other than the obvious one of a user passing a value <= 0 to the size argument, or an invalid pointer to the ptr argument (should I really even check for that in practical use)?I also observed an odd behavior that I still don't quite understand, so if you can explain that, then that would be much appreciated as well. Intel x64 Assembly - on Linuxclearmem:                         ; void clearmem( void* ptr, long size )    mov rcx, rsi                  ; copy rsi/size to rcx (aka the counter register)    next:                         ; for( long i = size; i > 0; i-- )        mov byte [rdi+rcx-1], 0   ;    *(reinterpret_cast<char*>(ptr+i-1)) = 0;    loop next                     ; dec rcx; cmp rcx, 0; jg next    ret                           ; returnIntel x64 Assembly - on Windowsclearmem proc    xchg rcx, rdx                 ; swap arg1 and arg2... windows uses rcx for arg1, and rdx for arg2    next:        mov byte ptr[rdx+rcx-1], 0    loop next    retclearmem endpExample usage in C++#include <iostream>// ...extern C void clearmem( void* ptr, long size );// ...int main( int argc, char* argv[] ){    int z[] = {1,2,3,4,5,6,7,8,9,10};    int zlen = sizeof(z) / sizeof(int);    std::cout << z[] before clearmem() = ;    print_array<int>(z, zlen);    clearmem(&z, sizeof(z));    std::cout << z[] after clearmem() = ;    print_array<int>(z, zlen);    return 0;}Output of C++ programz[] before clearmem() = 1,2,3,4,5,6,7,8,9,10z[] after clearmem() = 0,0,0,0,0,0,0,0,0,0Odd BehaviorIf I change all of the registers and variables to their 4 byte equivalent (e.g. rcx -> ecx, long -> int) then it still works fine in Windows, but on Linux it will segfault. I used GDB to set a break point on mov byte[rdi+rcx-1], 0 and used info registers to see the values in the registers and they were extrmely high. For instance rdi was 0x00007FFFFFFFE6E0 at the time, and considering I only have 16 GB of RAM, I would have expected a value less than 0x0000000400000000.What's going on here? Why does this work on Windows, but not on Linux? Note: Obviously, I know I shouldn't do this, but I like breaking things...
x64 assembly clearmem / zeromem
c++;linux;assembly;windows
I can't say I particularly like this code as it is right now. It seems to me that there are two reasonable approaches: if you think most of what you zero will be in main memory, then you probably just want the most compact code possible for the job. If you think it'll be used to zero data that might be in the cache a noticeable amount of the time, then you want to optimize for speed.For the former case, I'd probably do something like:mov rcx, rsixor rax, raxrep stosdRecent Intel (and, I believe, AMD) CPUs seem to have a special execution path that lets this run just about as fast as anything--if any more than a minuscule percentage of your data may be in main memory, it becomes difficult to measure the difference between this and the fastest code possible.If you really do want the fastest code possible, then you probably want to avoid complex instructions like loop, which is known to be sub-optimal on recent processors (anything since the Pentium Pro, really). For this, you want to use simple instructions for the loop:dec rcxtest rcx, rcxjnz loop_topAlthough the cmp rcx, 0 that you suggest in the comment will work, embedding the immediate value in the instruction makes it somewhat larger and (depending on CPU) somewhat slower to fetch. The test accomplishes the same goal (sets/clears Z-flag appropriately) without an immediate value. In this case, you probably want to zero an xmm register, then start with a (possible) maskmovdqu to fill in a partial word, in case the data is mis-aligned. Then do the main body of the loop using movdqa. Then have another (again, optional) maskmovdqu at the end to copy an partial-word tail that might be needed.If you're writing for an Intel processor (but not AMD) it's also worth considering a move to using AVX instructions instead. The current AVX instructions operate on 256-bit operands, and Intel has announced an AVX-512 instruction set that will (obviously enough) operate on 512-bit operands. For operands in main memory, you'll be limited by memory bandwidth either way, but if the data is in cache, this should give a substantial speedup. As far as AMD goes: they do have processors that can execute the current AVX instruction set, but it seems to be poorly enough tuned that performance gains from using it are minimal (at best). Then again, I haven't tried to test using them specifically for zeroing data--for such a simple task, it's possible it'll do better (but from what I recall, loads and stores seem like the bottleneck).