> while(true)
> {
> __asm__ __volatile__(
> ".align 8\n"
> "\tleal 2(%eax), %eax\n" /* 10 leals */
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> "\tleal 2(%eax), %eax\n"
> );
> leal++;
> }
> (void)signal(SIGALRM, dummy);
> (void)alarm(1);
> true++;
> while(true)
> {
> __asm__ __volatile__(
> ".align 8\n"
> "\taddl $2, %eax\n" /* 10 adds */
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> "\taddl $2, %eax\n"
> );
> addl++;
> }
...
Just curious, what happens to the time if they are mixed (addl between
the leal using different registers)? Doesn't the address calculation overlap
the arithmetic operation? The example looks rather artificial to demonstrate
the worst case by filling the hardware pipeline without the option of
re-ordering.
>Unfortunately, I see that much of the indexed address generation
>done in new versions of the C compiler abitrarily use LEA, followed
>immediately by the memory fetch using the newly generated address.
>This will be slower than simple math to obtain the address.
Doesn't hat sound more like a lack of proper optimization? If it were
optimized I would expect to see some addl on index registers mixed with
leal on other registers. I'm only a beginner at 80x86 assembler, but
the 68xxx did allow for some reordering and I thought re-ordering was one of
the advantages the newer (Pentium and greater) Intel processors could do
in the instruction pipeline.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:21 EST