From:	sime AT fly DOT cc DOT fer DOT hr (S. Mikecin)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Optimization
Date:	27 Nov 1996 16:41:16 GMT
Organization:	FER, Croatia
Lines:	21
Distribution:	world
Message-ID:	<57hqvc$e9u@bagan.srce.hr>
References:	<57hg9b$or5 AT kannews DOT ca DOT newbridge DOT com> <329C4CD4 DOT 7474 AT cornell DOT edu> <Pine DOT SUN DOT 3 DOT 90 DOT 961127095705 DOT 25056B-100000 AT coop10>
Reply-To:	sime AT fly DOT cc DOT etf DOT hr
NNTP-Posting-Host:	fly.cc.etf.hr
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Glen Miner (gminer AT ca DOT newbridge DOT com) wrote:
: > you might be better off just using ints (32 bits) instead of 8, or
: > worse, 16 bit quantities. 
: What makes you say that? I can't see how this would make it faster... 
: more cache misses, and an extra shift to index non-byte sized quantities. 
: Not to mention the fact that there are more byte sized registers.

: > most probably changing things from 32 bit quantities to 16 bit
: > quantities will make your program run slower because of the extra
: > indexing required.
: Extra indexing?! You'll have to justify that statement, cause' I'm not 
: buying it.

It is true that mostly 32-bit ints will be faster than 16-bit ints, because
of the instruction opcode. Instructions that work with 16-bit data have a
opcode prefix, so code will be a little slower. Well, it shouldn't be that
way also for (i)div or i(mul), but I'm not sure about it...

                                          <E-mail:     sime AT fly DOT cc DOT fer DOT hr    >
                                          <2nd E-mail: simun DOT mikecin AT fer DOT hr  >
                                          <URL:    http://fly.cc.fer.hr/~sime>

- Raw text -