Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!ptimtc!nntp-server.caltech.edu!suncub.bbso.caltech.edu!EYCHANER
From: eychaner@suncub.bbso.caltech.edu (Another casualty of applied metaphysics.)
Newsgroups: comp.lang.c
Subject: Re: Bug fix for Turbo C ?
Message-ID: <1991Jun29.213555.12911@nntp-server.caltech.edu>
Date: 29 Jun 91 21:35:55 GMT
References: <1991Jun26.155139.86965@vaxc.cc.monash.edu.au>,<1991Jun29.123505.21528@thunder.mcrcim.mcgill.edu>,<1991Jun29.190505.10335@nntp-server.caltech.edu>
Sender: news@nntp-server.caltech.edu
Reply-To: eychaner@suncub.bbso.caltech.edu
Organization: Big Bear Solar Observatory, Caltech
Lines: 50

I (Another casualty of applied metaphysics.) write:
>mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>>The New Testament says, on page 206 (A7.8, Shift Operators):
>>
>>	The value of E1>>E2 is E1 right-shifted E2 bit positions.  The
>>	right shift is equivalent to division by 2^E2 if E1 is unsigned
>>	or if it has a non-negative value; otherwise the result is
>>	implementation-defined.
>
>I have the following piece of code (shortened version):
>
>short a_250K_array[];
>int bit_shift, array_size, i;
>for (i = 0; i < arraysize; i++) a_250K_array[i] >>= bit_shift;
>
>What I want is to divide each member of the 250K short array by 2^bit_shift.
>The 250K array contains both positive and negative numbers.
>
>In Vax C 3.0 section 7.5.7 SEEMS to guarantee that this works by filling the
>vacated bits with a copy of E1's sign bit (and indeed, from experience, it
>does work as expected).

>One qualifier: this loop must be FAST.  And in my experience (so far),
>
>    a_250K_array[i] /= (1 << bit_shift);
>
>isn't as fast as the first method.  Is this the only ANSI legal way to do what
>I want to do?

(Actually, the first method appears to be ANSI legal but not necessarily
completely portable, as the result is "implementation-defined" rather than
"undefined".)  No one has yet suggested a better method than this on a machine
with undefined signed shifts; any takers?

>This particular section of the standard puzzles me; why impose this seemingly
>unnecessary constraint on the shift operators?  (Five thousand people will now
>write me explaining in great detail why it is necessary.)

Thanks to: dik@cwi.nl, raymond@math.berkeley.edu, and wirzeniu@cc.helsinki.fi
for their timely responses.  It is necessary beacuse some machines (i.e. Crays)
have no "shift-and-sign-fill" operator (and creating one creates a large drop
in performance).  Note that the ANSI standard says "implementation-defined"
rather than "undefined"; I can always hope that DEC continues to define the
implementation in a reasonable, backward-compatible way.  (Dream on again?)

-G.
******************************************************************************
Glenn Eychaner - Big Bear Solar Observatory - eychaner@suncub.bbso.caltech.edu
"There is no monopoly of common sense / On either side of the political fence"
                                                            -Sting, "Russians"