Path: utzoo!attcan!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Shifting question
Message-ID: <11566@steinmetz.ge.com>
Date: 19 Jul 88 14:40:34 GMT
References: <705@bnr-rsc.UUCP> <11556@steinmetz.ge.com> <2620@wright.mips.COM>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 30

In article <2620@wright.mips.COM> earl@mips.COM (Earl Killian) writes:
| In article <11556@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes:
| 
|    ... stuff I wrote ...

| 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.

  I consider this to be a major botch in an implementation,
*particularly* on fixed shifts where the problem can be detected at
compile time. There is *no* portable way to put in a check for shift out
of range, unless you check the range at runtime, which is possible but
messy. Guess it's a quality of implementation issue. I'm actually trying
to see what various C compilers do with this. Perhpas the only portable
way to do it is with a loop, one bit at a time.

  I think you were agreeing with me...
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me