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
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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>