Mail Archives: djgpp/2005/11/08/17:17:01
<cbramix AT libero DOT it> wrote in message
news:1131440321 DOT 197203 DOT 168820 AT z14g2000cwz DOT googlegroups DOT com...
> Hello,
> It's exactly you wrote into your commented assembly: the TEST
> opcode isn't needed.
It isn't needed and it does not cause execution speed
penalties either. I was curious and was timing your code:
The result was that both versions are executing at exactly
the same speed. Unfortunately I did not have the time
to manually remove the unneeded 'test' instruction, but
I am almost sure it wouldn't have caused any further
speed improvements.
> But as I wrote before, that instruction isn't emitted if I use a
> previous version, so I was wondering if the code could rewritten
> in a better way.
It probably could. But as mentioned before, it would not
make much of a difference.
> I make you another small example: let's see these C lines:
>
> (my_structure+0)->data = my_var++;
> (my_structure+1)->data = my_var++;
>
> The compiler generates this:
>
> movl %ebx, %eax
> leal 1(%ebx), %ebx
> movl %eax, (%esi)
> movl %ebx, %eax
> leal 1(%ebx), %ebx
> movl %eax, 4(%esi)
>
> But if I rewrite it to:
>
> (my_structure+0)->data = my_var;
> (my_structure+1)->data = ++my_var;
> my_var++;
>
> I get this:
>
> movl %ebx, (%esi)
> incl %ebx
> movl %ebx, 4(%esi)
> incl %ebx
So what? You have fed your compiler different code
and it gives you different assembly output. Without
having tested this example of yours I am again
almost certain that you are getting about the
same quality of code in both cases even if it does
not look the same to you.
A further explanation: You have listed above two
examples for assembly code generation. I am almost
sure that you prefer the second example over the first
one, right? But the first example shows the typical
interleaving scheme which was very important for
several Pentium generations. It might not please the
programmer's eye, but it is nevertheless 'excellent food'
for most types of Pentiums.
> DJ said it's probably better to forward this message to
> GCC mailing list and now I'm going to believe he's right.
You can always do that if you believe that the compiler
is supposed to generate exactly the same machine
code for varying, but logically identical, code inputs.
I am just afraid that Gnu's GCC has not arrived at
this level yet - and it probably never will. GCC is an
excellent compiler but you should not expect it to
always generate the best code possible.
> Thank you for your help.
>
> Sincerely,
>
> Carlo Bramini
>
Ciao.
- Raw text -