Posts

Showing posts with the label x86

Not understanding FLAGS status register

Not understanding FLAGS status register I was helping a friend of mine doing some computer architechture theory exercises. We stumbled on this m.c. exercise about the FLAGS register and don't really know how to answer it. It goes on something like this: "Assume that you've performed an ADD operation between two unsigned integer numbers, and that it resulted in the following flags setting: CF = 0; OF = 1; ZF=0; SF=1 . What can we conclude from this setting and why?" The correct choice states that the result of that operation is correct, and when saying why, it states " because the CF equals zero". My question here is why do we only need to consider the carry flag when there are other flags set to one? And also, how is possible for the overflow and the signed flag to be set to one when we are performing an add operation between to unsigned integers? Thanks in advance! 2 Answers 2 ...

Does any of current C++ compilers ever emit “rep movsb/w/d”?

Does any of current C++ compilers ever emit “rep movsb/w/d”? This question made me wonder, if current modern compilers ever emit REP MOVSB/W/D instruction. REP MOVSB/W/D Based on this discussion, it seems that using REP MOVSB/W/D could be beneficial on current CPUs. REP MOVSB/W/D But no matter how I tried, I cannot made any of the current compilers (GCC 8, Clang 7, MSVC 2017 and ICC 18) to emit this instruction. For this simple code, it could be reasonable to emit REP MOVSB : REP MOVSB void fn(char *dst, const char *src, int l) { for (int i=0; i<l; i++) { dst[i] = src[i]; } } But compilers emit a non-optimized simple byte-copy loop, or a huge unrolled loop (basically an inlined memmove ). Do any of the compilers use this instruction? memmove For that loop (without __restrict ), or ever? gcc has -mmemcpy-strategy=rep_4byte and -minline-all-stringops to override the tuning options. gcc.gnu.org/onlinedocs/gcc/x86-Options.html. ...