From: "Alexei A. Frounze" 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: <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