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
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

- Raw text -