Path: utzoo!attcan!uunet!husc6!mailrus!ames!vsi1!wyse!mips!earl
From: earl@mips.COM (Earl Killian)
Newsgroups: comp.arch
Subject: Re: Shifting question
Message-ID: <2620@wright.mips.COM>
Date: 19 Jul 88 04:45:15 GMT
References: <705@bnr-rsc.UUCP> <11556@steinmetz.ge.com>
Lines: 27
In-reply-to: davidsen@steinmetz.ge.com's message of 18 Jul 88 15:19:38 GMT

In article <11556@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes:

   From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
   Date: 18 Jul 88 15:19:38 GMT

    I would certainly think so. The action of a shift on an unsigned is
   pretty well defined, and the compiler you mention is not doing it. x>>32
   should work the same on any machine, 8, 16, 32, or 64 bits. Also, the
   action of doing:
	   x >>= 16; x>>= 16;
   better be the same as:
	   x = x>>32;

By extension
	x >>= 16; x >>= 16; x >>= 16; x >>= 16;
	x >>= 16; x >>= 16; x >>= 16; x >>= 16;
	x >>= 16; x >>= 16; x >>= 16; x >>= 16;
	x >>= 16; x >>= 16; x >>= 16; x >>= 16;
should give the same answer as
	x >>= 256;
but I doubt very many C implementations do this.  Most architectures
look at 5, 6, 7, or 8 bits of the shift count.  It always seemed
inconsistent to me to look are more than 5 (i.e. log2(bitsperword))
without looking at all of them.
-- 
UUCP: {ames,decwrl,prls,pyramid}!mips!earl
USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086