From:	"John S. Fine" <johnfine AT erols DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Optimum code ?
Date:	Wed, 03 Nov 1999 15:31:26 -0500
Lines:	31
Message-ID:	<38209B9E.4004@erols.com>
References:	<7vq3td$ojb$1 AT tron DOT sci DOT fi>
Mime-Version:	1.0
X-Trace:	Qr5INUKCBh4QBuiUYoBCTTAtQQiAx8waL0L0mJhFP+Q=
X-Complaints-To:	abuse AT rcn DOT com
NNTP-Posting-Date:	3 Nov 1999 20:34:04 GMT
X-Mailer:	Mozilla 3.01 (Win95; U)
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

stefan fröberg wrote:

> Which of the following assembling methods gives the fastest graphic code
> possible ?
> - Using NASM (yiepee !).
> - Using GAS (oh no !)
> - Using inline AT&T (aaarghh !)

  The big differences in speed result from how well you design and
code your routines, not from which assembler you select.

  If your routines rapidly alternate short ASM sequences with short
C sequences, then the overhead of the call/ret for NASM or GAS
would eliminate any savings from coding in ASM, so the only
reasonble choice would be inline.

  If you can execute many interations of the ASM code before
returning to C code, then the call/ret overhead won't matter
as much.

  GAS will often select a shorter encoding of an instruction
than the default encoding selected by NASM.  If you let NASM
select longer encodings that may result in some extra cache
misses and slow the code down some.  If you really care about
that and don't want to use GAS, you can just review your
ASM source by hand and insert "BYTE" and "SHORT" overrides
wherever they are appropriate to get the same short encodings
GAS would have selected.
-- 
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/

- Raw text -