Most game programmers will stick with >> and << with bitshifting. Its really not worth the time to make the shifts inline with asm. Its not too common practice. And the speed increases, which probably might not exist, aren''t even worth the miniscule amount of speed they provide, if there is any.

I don''t know how a mul was faster than a bit shift, that will never be true (as long as computers store data in binary format). Though on newer processors (newer being anything greater than a plain p2), a mul is coming down to a single computer cycle. Division is different, always try and use >> for division as a div or idiv instruction can take up to 12 times as long.

Well, it''s possible that the compiler was automatically converting the multiplication operator into the relevant bitshifts, but in a more optimised way than the compiled manual bitshifts.

This is only theoretical, but this is how it might have turned out...

x = y * 320;
------------
MOV EAX, y
MOV EBX, EAX
SHL EAX, 6
SHL EBX, 8
ADD EAX, EBX
MOV x, EAX
------------
Nice and quick.

x = (y << 6) + (y << 8);
------------
MOV EAX, y
XOR EBX, EBX
SHL EAX, 6
ADD EBX, EAX
MOV EAX, y
SHL EAX, 8
ADD EBX, EAX
MOV x, EBX
------------
Maybe an extreme example, but this is the general idea.

I''m no ASM guru, but what I saw in the asm listing was quite different. It didn''t have any shls.

It looked something like this

mov EAX, y
imul EAX, 320

The only thing I actually remember is the imul instruction, instead of shl. So I guess VC++6 Std doesn''t optimize like that.