Xref: news2.mv.net comp.os.msdos.djgpp:5974
From: Paul Shirley <Paul AT chocolat DOT foobar DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Setpixel in AT&T inline asm....
Date: Sun, 14 Jul 1996 15:55:46 +0100
Organization: DrinkSoft
Lines: 28
Distribution: world
Message-ID: <v9yAuDAypQ6xEwLa@chocolat.foobar.co.uk>
References: <4rh0g5$m9r AT twain DOT mo DOT net> <4rj0kb$sf3 AT nef DOT ens DOT fr>
	<836948271snz AT tsys DOT demon DOT co DOT uk> <4s4sue$qbc AT status DOT gen DOT nz>
NNTP-Posting-Host: chocolat.foobar.co.uk
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <4s4sue$qbc AT status DOT gen DOT nz>, Bruce Foley
<brucef AT central DOT co DOT nz> writes
>>Although I've never used setpixel routines, I was always under the impression
>>that (x + y << 8 + y << 6) is faster than (x + 320 * y).
>
>>.splitbung
>>-- 
>>* TQ 1.0 * The 'Just So Quotes'.
>>OJ's WWW address is http://////////
>
>I think this is true of older processors, but on a 486, a
>well designed mul instruction is just as fast (or faster?),
>depending on the value of the operands.
>Don't know about the Pentium though, since simple
>instructions can be useful for keeping both Pipes going.
>-Optimising is a hell of a thing...
>

An imul or mul op on P5 and lower is *slow* (13 clks). (A floating point
fmul is fast!)

However its actually irrelevant, just trust gcc to do the right thing
with *CONSTANT. For *320 it generates a 'lea  eax,[eax+4*eax];sal eax,6'
pair, which is the same as the shift code above.


-- 
Paul Shirley