HS> compilers compiling that fastest code possible".
 HS> Lets see now, where did I say that a compiler doesn't optimize?
 HS> Does a compiler change a *256 to a <<8?
Actually, it does.
 HS> Obviously not, so why not optimize it yourself?
You "obviously" are wrong, so why not admit it?
 HS> But according to you thats wrong so don't do it.
He's right - don't.  We've already gone through a thread like this, we don't 
need another one.
Let's just show you what a compiler does.  This is Watcom 10.6:
===t.cc===
int main()
{
    unsigned int n = 8;
    unsigned int m = n * 12;
    unsigned int o = m * 256;
    return 0;
}
===t.cc===
Simple enough.  We have a *12, and a *256.  Let's see what happens...  (I'm 
gonna remove extraneous assembly code simply to shorten the message.)
My modifications and comments are shown in C++ style commenting.
===t.lst===
int main()
{
// push registers, set up stack, eliminated
    unsigned int n = 8;
 000e  c7 45 f4 08 00 00 
       00                                mov     dword ptr -0cH[ebp],00000008
H
// should be straight forward - putting 8 in the first position on the stack.
    unsigned int m = n * 12;
 0015  6b 45 f4 0c                       imul    eax,-0cH[ebp],0cH
 0019  89 45 f8                          mov     -8H[ebp],eax
// integer multiply, and save it.  Not a big problem.
    unsigned int o = m * 256;
 001c  8b 45 f8                          mov     eax,-8H[ebp]
 001f  c1 e0 08                          shl     eax,08H
 0022  89 45 fc                          mov     -4H[ebp],eax
// shl?  WHAT?  A SHIFT?  I thought you said it wouldn't do that!
// This is WITH NO OPTIMIZATIONS ON.  In fact, they've BEEN TURNED OFF.
    return 0;
// blah, blah - set up return value deleted.
}
// restoring registers and stack removed
// lots of other garbage summaries removed
===t.lst===
I believe you owe Carey an apology.  And yourself a little more education.
--- Maximus/2 3.01
---------------