Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #60620 > unrolled thread

Negative shift counts

Back to article view | Back to comp.lang.c

Contents

  Negative shift counts Noob <root@127.0.0.1> - 2015-04-21 11:33 +0200
    Re: Negative shift counts David Brown <david.brown@hesbynett.no> - 2015-04-21 12:22 +0200
      Re: Negative shift counts Noob <root@127.0.0.1> - 2015-04-21 13:12 +0200
    Re: Negative shift counts Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 12:02 +0100
    Re: Negative shift counts glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-29 20:08 +0000

#60620 — Negative shift counts

Hello,

I am aware that negative shift counts have undefined behavior.

   int i = 40 << -2; // UB

It seems to me that a natural way to extend shift counts to
negative values would be to just flip the shift direction.

The above statement would behave "as if" we'd written

   int i = 40 >> 2;


I suppose negative shift counts were unsupported in the original
language definition (?) in the 70s and remained unsupported in the
first edition of K&R C? Perhaps this was done to save space when
RAM was tight, and such a "feature" was not considered to bring
any value?

Then ANSI saw no benefit to discuss defining the behavior during
the standardization process in the 80s? Because no implementation
offered this as an extension?

I'm perplexed, because it seems to be a trivial extension, with
low complexity, for a small gain in expressiveness.

Do you see perhaps other ways to define the behavior of negative
shift counts that would be at odds with the one proposed above?

Regards.

[toc] | [next] | [standalone]

#60626

On 21/04/15 11:33, Noob wrote:
> Hello,
> 
> I am aware that negative shift counts have undefined behavior.
> 
>   int i = 40 << -2; // UB
> 
> It seems to me that a natural way to extend shift counts to
> negative values would be to just flip the shift direction.
> 
> The above statement would behave "as if" we'd written
> 
>   int i = 40 >> 2;
> 
> 
> I suppose negative shift counts were unsupported in the original
> language definition (?) in the 70s and remained unsupported in the
> first edition of K&R C? Perhaps this was done to save space when
> RAM was tight, and such a "feature" was not considered to bring
> any value?
> 
> Then ANSI saw no benefit to discuss defining the behavior during
> the standardization process in the 80s? Because no implementation
> offered this as an extension?
> 
> I'm perplexed, because it seems to be a trivial extension, with
> low complexity, for a small gain in expressiveness.
> 
> Do you see perhaps other ways to define the behavior of negative
> shift counts that would be at odds with the one proposed above?
> 
> Regards.

The conversion between shift directions is trivial when the shift count
is constant - much less so when it is variable.

[toc] | [prev] | [next] | [standalone]

#60630

On 21/04/2015 12:22, David Brown wrote:
> On 21/04/15 11:33, Noob wrote:
>> Hello,
>>
>> I am aware that negative shift counts have undefined behavior.
>>
>>    int i = 40 << -2; // UB
>>
>> It seems to me that a natural way to extend shift counts to
>> negative values would be to just flip the shift direction.
>>
>> The above statement would behave "as if" we'd written
>>
>>    int i = 40 >> 2;
>>
>>
>> I suppose negative shift counts were unsupported in the original
>> language definition (?) in the 70s and remained unsupported in the
>> first edition of K&R C? Perhaps this was done to save space when
>> RAM was tight, and such a "feature" was not considered to bring
>> any value?
>>
>> Then ANSI saw no benefit to discuss defining the behavior during
>> the standardization process in the 80s? Because no implementation
>> offered this as an extension?
>>
>> I'm perplexed, because it seems to be a trivial extension, with
>> low complexity, for a small gain in expressiveness.
>>
>> Do you see perhaps other ways to define the behavior of negative
>> shift counts that would be at odds with the one proposed above?
>>
>> Regards.
>
> The conversion between shift directions is trivial when the shift count
> is constant - much less so when it is variable.

This makes complete sense.

Thanks for pointing out the obvious part I was missing.

Regards.

[toc] | [prev] | [next] | [standalone]

#60629

Noob <root@127.0.0.1> writes:

> I am aware that negative shift counts have undefined behavior.
>
>   int i = 40 << -2; // UB
>
> It seems to me that a natural way to extend shift counts to
> negative values would be to just flip the shift direction.
>
> The above statement would behave "as if" we'd written
>
>   int i = 40 >> 2;
>
>
> I suppose negative shift counts were unsupported in the original
> language definition (?) in the 70s and remained unsupported in the
> first edition of K&R C? Perhaps this was done to save space when
> RAM was tight, and such a "feature" was not considered to bring
> any value?

The original view of C was that it should not offer very much over and
above what the machine offers.  The structuring (blocks, ifs, loops
etc.) is no more than thin syntax over tests and jumps.  Functions in C
can't be nested because most machines offer little more than stack
pointer relative addressing.

A higher-level shift would require (on some systems) code to do checks
every time, except in those probably rare cases when the compiler can
optimise 40 << -2 into 40 >> 2.  That's the sort of universal cost that
C tries to avoid.

> Then ANSI saw no benefit to discuss defining the behavior during
> the standardization process in the 80s? Because no implementation
> offered this as an extension?
>
> I'm perplexed, because it seems to be a trivial extension, with
> low complexity, for a small gain in expressiveness.

It certainly simple (low complexity) but it's not zero-cost, and the
cost has to be set against with the ease with which an inline function
can be written to do the job.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#61275

Noob <root@127.0.0.1> wrote:
 
> I am aware that negative shift counts have undefined behavior.
 
>   int i = 40 << -2; // UB
 
> It seems to me that a natural way to extend shift counts to
> negative values would be to just flip the shift direction.
 
> The above statement would behave "as if" we'd written
 
>   int i = 40 >> 2;

The shift operators follow what much hardware does.  If you happen
to be on a PDP-10, then most likely your negative shifts do what 
you ask, as that is what the hardware does. 

Otherwise, it requires a conditional branch on each one, likely
much slower than the shift itself.  Note also that most hardware
uses only some bits of the shift amount.

Note that the Fortran ISHFT function does shift left or right based
on the sign. Hopefully the compilers optimize for the constant case.

-- glen

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web