From: Kester Maddock <dmaddock AT xtra DOT co DOT nz>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: How to make DJGPP treat an int as 16-bit in size.
Date: Thu, 13 Aug 1998 18:56:30 +1200
Organization: Customer of Telecom Internet Services
Lines: 36
Message-ID: <35D28E1D.A118D67E@xtra.co.nz>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980803163922 DOT 3493A-100000 AT is> <35CA13A8 DOT 31E1F541 AT unb DOT ca> <35CA4576 DOT 7CE600EB AT cartsys DOT com>
NNTP-Posting-Host: p42-m16-wn4.dialup.xtra.co.nz
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
Precedence: bulk

Nate Eldredge wrote:

> Endlisnis wrote:
> >
> > Eli Zaretskii wrote:
> >
> > > More accurately, use int where its size doesn't matter and you want the
> > > fastest code, and short/long where the size matters.
> >
> >      Are you saying that 'int's are faster than 'short's in DJGPP?
>
> They are.  The x86 can execute 32-bit instructions just as fast as
> 16-bit ones.  However, when in protected mode, the 32-bit form is the
> default.  To execute the 16-bit form requires a one-byte prefix (66h,
> usually).  This adds a byte to the size of the code, and also requires
> an additional cycle to decode.
>
> That is not necessarily true in general, but often is.
> --
>
> Nate Eldredge
> nate AT cartsys DOT com

  In a source file I saw recently, the programmer had commented: "Change to
shorts so
fits in the CPU cache better."  This is DJGPP code (of course :-)  This does of
course
make sense to me.
So which is faster: shorts, from the cache, but with the 16 bit override, or
ints (longs) with no 16 bit overide but possibly overflowing the cache?
The array has between 322 to about 1080 elements.


Kester Maddock
dmaddock AT xtra DOT co DOT nz