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: Thu, 13 Apr 2000 22:10:59 +0400
Organization: MTU-Intel ISP
Lines: 25
Message-ID: <38F60DB3.E355975@mtu-net.ru>
References: <38F20E7A DOT 3330E9A4 AT mtu-net DOT ru> <38F23A21 DOT A59621A1 AT inti DOT gov DOT ar> <38F49A45 DOT 13F0AB1 AT mtu-net DOT ru> <8d4ca1 DOT 3vvqqup DOT 0 AT buerssner-17104 DOT user DOT cis DOT dfn DOT de>
NNTP-Posting-Host: ppp103-131.dialup.mtu-net.ru
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
X-Trace: gavrilo.mtu.ru 955656358 66507 212.188.103.131 (13 Apr 2000 20:05:58 GMT)
X-Complaints-To: usenet-abuse AT mtu DOT ru
NNTP-Posting-Date: 13 Apr 2000 20:05:58 GMT
X-Mailer: Mozilla 4.61 [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:
> It would be interesting to know, what the performance difference
> of this code and the code without the inline assembly was.

Well, I don't think it's possible to write extremely fast 3d renderer w/o ASM at
all (at least on i386+ CPUs). Don't you think Wolf3d, Doom, Descent and Quake
would not be as fast as they are, if they were written in pure C (even Watcom C,
which was one of the best compilers then)?

> But, why use this? Gcc will most probably produce exactly the
> same code by
> 
>   du >>= SUB_BITS;
>   dv >>= SUB_BITS;

It will load EAX, shift EAX and put the result back instead of plane shift using
a memory reference. At least I saw this in disassembly.

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