OSDev.org

Code Slasher wrote:Also you need to know what you are doing to get it right, just as i stated before!

I maintain that you need to be a better at writing assembly code than the compiler authors are at writing optimizers. Very few people fall into that category, and I've not seen any evidence that anyone posting to this board (myself included) is one of these people.

By the way, a loop consisting of MOV instructions (such as that generated by a compiler) is generally faster on modern CPUs than a single REP STOSB or REP MOVSB.

Code Slasher wrote: hi,
I didn't say WRITE FULL PROGRAMS IN ASM! Said ROUTINES! Also any ROUTINE that is called A LOT or is used in LOOPS is a candidate for ASM optimization. Also you need to know what you are doing to get it right, just as i stated before!

Now, there's no need to shout, is there?

Hi,

I am not trying to brag, but I am not an ASM guru, not even close but many times I have been able to write better ASM code than the gcc compiler, hands down. The problem with compilers is that they must always be generic, they can never know the exact purpose of a piece of code so they must write a set of op codes that is generic to the situation in which the code is used. Don't get me wrong, as I said I couldn't beat a compiler in any huge functions, for example I wrote a printf type function in asm that worked perfectly, until I needed to add recursion for writing strings inside the buffer using the '%s' control code, for some reason I just couldn't get it to work, but I wrote the same function in C, and you guessed it, worked like a dream. My point is you don't have to be a guru to beat the compiler in some cases, it just depends on what you need to do. Most of the time the compiler will win hands down, but sometimes, if only a few, it can be beaten.

-PlayOS

Tim Robinson wrote: By the way, a loop consisting of MOV instructions (such as that generated by a compiler) is generally faster on modern CPUs than a single REP STOSB or REP MOVSB.

Interesting, I was unaware of this. Why would that be? My first thought is that it is because of instruction pipelining (the original purpose of the rep instructions was so that certain common loops could be done without repeated instruction fetches; pipelining would make that moot for a sufficiently small loop), but I would like to hear more. Most of my optimization knowledge is admittedly out of date, but even some recent books speak of using rep for efficiency.

According to How to optimize for the Pentium family of microprocessors: (emphasis is mine)

On the PPlain, a prefixed instruction can only execute in the U-pipe, except for conditional near jumps.

On the PMMX, instructions with operand size, address size, or 0FH prefix can execute in either pipe, whereas instructions with segment, repeat, or lock prefix can only execute in the U-pipe.

However:

REP MOVS and REP STOS can perform very fast by moving an entire cache line at a time on PPro, PII and PIII. This happens only when the following conditions are met:

• both source and destination must be aligned by 8
• direction must be forward (direction flag cleared)
• the count (ECX) must be greater than or equal to 64
• the difference between EDI and ESI must be numerically greater than or equal to 32
• the memory type for both source and destination must be either writeback or write-combining (you can normally assume this).

It seems to me that:

• using the REP prefix defeats pairing, which would slow things down for many short moves
• using MOVSD is much more efficient than MOVSB for a memcpy-type routine

The document also points out that a 32-bit CMP in a loop is much faster than REP SCASB, for a strlen-type routine.

Read the document, and the Intel guides, and draw your own conclusions.

In general the more complex the instruction the less attention has been paid to optimising it as the x86 processor family has evolved, the rep style instructions fall into this category (Note that I said in general, I'm well aware MMX etc has improved). This is why you often find that optimised routines on a 386 using those kinds of instructions will run slower on pentium than the same routine using simpler instructions.

As for the REP issue, I really don't like the idea of giving up on the V pipe for the length of time the REP instruction is executing. Intel has blessed us with 2 execution units, we might as well make use of them both.

I guess it comes down to a compromise. If you think you can keep the V pipe occupied then use MOV, if not then you won't get penalised for using REP because you can't pair 2 memory accesses anyway.