Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34E7FAAA.12EC@rug.ac.be>
Date: Mon, 16 Feb 1998 09:36:58 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
To: Erik Max Francis <max AT alcyone DOT com>
Cc: djgpp AT delorie DOT com
Subject: Re: Allegro ex11.c
References: <34DF7294 DOT 21D0 AT home DOT com> <34e39746 DOT 1884750 AT news DOT compusmart DOT ab DOT ca> <34E7EFA0 DOT 6DF9E92 AT alcyone DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Erik Max Francis wrote:
> 
> Demandred wrote:
> 
> > Hmmm... random() returns a random (duh) integer that can be pretty
> > huge (0 to MAXINT, IIRC), so I'd guess that the & 7 (bitwise AND with
> > 111b) acts like a % 8 (modulus 8)(??).  Why, I don't know... maybe
> > bitwise AND is faster than mod?
> 
> x%n is the same as x&(n - 1), when n is a power of 2.
> 
> Bitwise operations are much, much faster than integer division operators
> (/, %).

However, since our gcc compiler is smart enough to see that modulus
operations with a divisor which is a power of 2, can be implemented as
bitwise operations, it may be a better choice to choose for ::operator%
rather than ::operator&, especially when the divisor is not a integer
literal, but a symbolic constant.

e.g. the libc.a "rand ()" function, returns and integer between 0 and
RAND_MAX, by doing something like "sd & RAND_MAX". This works well as
long as no one decides to alter RAND_MAX to be different from a constant
like 2^n-1, otherwise it will fail.
On the other hand "sd % (RAND_MAX+1)" will always produce the expected
result, and the compiler will produce equally efficient code if
possible.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/