Mail Archives: djgpp/2000/04/14/11:03:26
Alexei A. Frounze wrote:
>Dieter Buerssner wrote:
>>
>> Alexei A. Frounze wrote:
>>
>> I have not said, that the plain C code would be faster or slower.
>> I just asked a question, that may be not to difficult to answer
>> for you, because the C code is already there, in comments.
Note, that I was refering to the T_Map function here, that does
not need to fiddle with the FPU control word.
>Not really. Actually, my ASM code improves the performance greatly. And
Can you quantify this.
>I can't copmare ASM vs optimized plain C because GCC/AS doesn't compile
>the source with -O2 switch.
Why not? With all the usages of the adress off operater "&", gcc
won't be able to optimize your code very much. If you use &var, usually
var cannot be kept in a register. I have shown you one example,
where this can be clearly seen. Also, the inner loops seem to be
almost totally written in inline assembler, so you can't expect
much optimization anyway.
To "fix" your code temporarily, you could try to replace all
"g", with "r", and add "memory" to the clobber list. But of course,
you shouldn't do this blindly. Then you may be able to compile it
with -O2. Post the results.
>> Not here. When compiling your code with gcc -O -S (gcc 2.95.2),
>> for the interesting lines
>> So, this happens to produce correct code, even if the inline
>> assembly is wrong, as I explained in another post.
After looking at my own post, I am not sure, whether this is
correct. There are two occurences of the code snippet in the
source. I looked at the assembler output of one, that seemed correct.
I pasted the other, and that seems incorrect. Anyway, the C code produces
better assembly, as your inline code with the references could ever do.
>But -O is not enough for me. ;) I still need -O2.
Then try it yourself with -O2, it does take less than a minute,
and you will see no significant difference.
As you have noted, gcc may have optimization bugs. (It for sure
has, I have found at least one in the current verion.) But
throwing buggy code at gcc and then complaining, is hardly
a mean to prove this.
One final suggestion: Stay away from inline assembly (yet).
I have seen some snippets you have posted (and mailed),
and almost all of them were clearly wrong.
To cite Donald E. Knuth from memory:
"Premature optimization is the devil of all programming."
--
Regards, Dieter
- Raw text -