From: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: inefficiency of GCC output code & -O problem
Date: Wed, 19 Apr 2000 19:13:25 +0400
Organization: MTU-Intel ISP
Lines: 76
Message-ID: <38FDCD15.7BC68C13@mtu-net.ru>
References: <Pine DOT LNX DOT 4 DOT 10 DOT 10004161837540 DOT 1138-100000 AT darkstar DOT grendel DOT net> <38F9D717 DOT 9438A3F6 AT mtu-net DOT ru> <8df84a DOT 3vvqu6v DOT 0 AT buerssner-17104 DOT user DOT cis DOT dfn DOT de> <38FB4094 DOT DE7B5F4C AT mtu-net DOT ru> <8dfum2 DOT 3vvqu6v DOT 0 AT buerssner-17104 DOT user DOT cis DOT dfn DOT de> <38FB7858 DOT 41B090DB AT mtu-net DOT ru> <8dh6kr DOT 3vvqvqr DOT 0 AT buerssner-17104 DOT user DOT cis DOT dfn DOT de> <38FC0E77 DOT 904B12BE AT mtu-net DOT ru> <8dibun DOT 3vvqvqr DOT 0 AT buerssner-17104 DOT user DOT cis DOT dfn DOT de>
NNTP-Posting-Host: ppp103-64.dialup.mtu-net.ru
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
X-Trace: gavrilo.mtu.ru 956163933 29012 212.188.103.64 (19 Apr 2000 17:05:33 GMT)
X-Complaints-To: usenet-abuse AT mtu DOT ru
NNTP-Posting-Date: 19 Apr 2000 17:05:33 GMT
Cc: buers AT gmx DOT de
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en,ru
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Dieter Buerssner wrote:
> I made a joke. I am no native English speaker (neither are you).
> Perhaps, the joke was bad/wrong. Don't you see, that a plane C
> (not *plain*), should be able to texture planes quite efficiently.
> I just thought, this was a *nice* misspelling.

I see. :)

> >> >      };
> >>         ^
> >> Why this semicolon? The same thing I see everywhere in your sources.
> >
> >Do you think this semicolon makes something slower?
> 
> No. But why the semicolon. It seems highly unconventional to me.

But not for me. Let me explain it... First programming language that I've learnt
is Pascal (I don't say about Basic, because IMHO it's not a PL, it's something
for beginners and dummies :). In Pascal composite operators are made this way:

BEGIN
  operator1;
  operator2;
END;
   ^ this semicolon must be present always.

So there is nothing surprising that I still put this semicolon in C. Btw, the
semicolon after "operator2" is not really needed in Borland Pascal, but such
semicolon is always needed in C before "}".

> 
> [code snipped]
> 
> >And they differ. 57 vs 70. Is it an improvement???
> 
> I don't doubt your numbers at all. 

And I don't believe yours. :) Really. Your code works here either the same as
before or slower. If I remove span() and put your code, it runs slower. If I
throw away the FIDIVRL rep[lacing it with plane C, it also runs slower. The rest
of the code doesn't matter. It works almost the same in both C and ASM.

> Perhaps in my configuration, the
> speed is limited by the access to the screen, and not in your config.
> But it is clear, that the interface change (pointers vs. integer)
> could make a small difference. When you call span(..., &u1, &u2, ...),
> gcc most probably will not be able to hold u1 and u2 in registers.
> 
> I already said, that your ASM for span looks highly optimized,
> so I was really surprised by my findings. It may also be a
> BUG in my CPU, or a cache issue. Your version unrolls by an higher
> factor.

Btw, it's possible to speed up my ASM a bit too. Just replace what goes after
"_span_1" label with the following:
------------8<--------------
_span_1:
        mov     al, [ebx]
        mov     [edi], al
_span_0:

        pop     edi
        pop     esi
        pop     ebx
        pop     ebp
        ret
------------8<--------------
There was some dead/redundant code.

bye.
Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror:   http://members.xoom.com/alexfru