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

Groups > comp.lang.c++ > #7978 > unrolled thread

Unexpected Rotate?

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

Contents

  Unexpected Rotate? "Michael D. Berger" <m_d_berger_1900@yahoo.com> - 2011-07-19 16:48 +0000
    Re: Unexpected Rotate? "Balog Pal" <pasa@lib.hu> - 2011-07-19 18:58 +0200
      Re: Unexpected Rotate? "Paul" <pchristor@yahoo.co.uk> - 2011-07-19 23:20 +0100
        Re: Unexpected Rotate? Bart van Ingen Schenau <bart@ingen.ddns.info> - 2011-07-20 10:41 +0200
    Re: Unexpected Rotate? Leigh Johnston <leigh@i42.co.uk> - 2011-07-19 18:00 +0100
    Re: Unexpected Rotate? Andy Champ <no.way@nospam.invalid> - 2011-07-19 21:02 +0100
      Re: Unexpected Rotate? "Bo Persson" <bop@gmb.dk> - 2011-07-19 23:52 +0200
        Re: Unexpected Rotate? James Kanze <james.kanze@gmail.com> - 2011-07-20 12:57 -0700
          Re: Unexpected Rotate? "Michael D. Berger" <m_d_berger_1900@yahoo.com> - 2011-07-21 02:10 +0000
            Re: Unexpected Rotate? "Balog Pal" <pasa@lib.hu> - 2011-07-21 11:10 +0200
              Re: Unexpected Rotate? Andy Champ <no.way@nospam.invalid> - 2011-07-21 20:35 +0100
              Re: Unexpected Rotate? James Kanze <james.kanze@gmail.com> - 2011-07-22 10:33 -0700

#7978 — Unexpected Rotate?

With:
g++ --version
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)

On:
uname -a
Linux mbrc40 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686 
i686 i386 GNU/Linux
(A Centos box)

Running the program:
   uint64_t    mask = 0x8000000000000000ULL;
   cout << "mask = 0x" << hex << mask << endl;
   cout << "mask>>63 = 0x" << hex << (mask>>63) << endl;
   cout << "mask>>64 = 0x" << hex << (mask>>64) << endl;

I get:
mask = 0x8000000000000000
mask>>63 = 0x1
mask>>64 = 0x8000000000000000

Why is the final value not: 0x0 ?

Thanks for your comments.
Mike.

[toc] | [next] | [standalone]

#7979

"Michael D. Berger" <m_d_berger_1900@yahoo.com>
>   uint64_t    mask = 0x8000000000000000ULL;
>   cout << "mask>>64 = 0x" << hex << (mask>>64) << endl;
>
> I get:
> mask>>64 = 0x8000000000000000
>
> Why is the final value not: 0x0 ?

the second operand of shift must be  0 <= op < bits. Otherwise behavior is 
undefined. For your case 63 is the maximum legal  value. (lazi to quote the 
stadard, but it is there right in the first point. 

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

#7987

"Balog Pal" <pasa@lib.hu> wrote in message 
news:j04d35$20ht$1@news.ett.com.ua...
> "Michael D. Berger" <m_d_berger_1900@yahoo.com>
>>   uint64_t    mask = 0x8000000000000000ULL;
>>   cout << "mask>>64 = 0x" << hex << (mask>>64) << endl;
>>
>> I get:
>> mask>>64 = 0x8000000000000000
>>
>> Why is the final value not: 0x0 ?
>
> the second operand of shift must be  0 <= op < bits. Otherwise behavior is 
> undefined. For your case 63 is the maximum legal  value. (lazi to quote 
> the stadard, but it is there right in the first point.
>
So what if its undefined?
Does that mean it;s impossible?

It seems like some buzzword to say something is indefined or no-standard or 
whatever but who gives a fuck. I guess from your respect of deifnition that 
you are not thew author of the latest MS virus worm. Or maybe you are THE 
worm ;~) 

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

#7996

Paul Wrote:

> 
> "Balog Pal" <pasa@lib.hu> wrote in message
> 
> news:j04d35$20ht$1@news.ett.com.ua...
> > "Michael D. Berger" <m_d_berger_1900@yahoo.com>
> >>   uint64_t    mask = 0x8000000000000000ULL;
> >>   cout << "mask>>64 = 0x" << hex << (mask>>64) << endl;
> >>
> >> I get:
> >> mask>>64 = 0x8000000000000000
> >>
> >> Why is the final value not: 0x0 ?
> >
> > the second operand of shift must be  0 <= op < bits. Otherwise
> > behavior is 
> > undefined. For your case 63 is the maximum legal  value. (lazi to
> > quote 
> > the stadard, but it is there right in the first point.
> >
> So what if its undefined?
> Does that mean it;s impossible?

It means that the combination of compiler & CPU can do anything it likes and
it does not even have to be consistent about it.
The most likely results in this case are:
- The top bits of the shift-value are ignored (this is done, for example, by
x86 CPUs)
- The operator results in the value 0

Bart v Ingen Schenau

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

#7980

On 19/07/2011 17:48, Michael D. Berger wrote:
> With:
> g++ --version
> g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>
> On:
> uname -a
> Linux mbrc40 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686
> i686 i386 GNU/Linux
> (A Centos box)
>
> Running the program:
>     uint64_t    mask = 0x8000000000000000ULL;
>     cout<<  "mask = 0x"<<  hex<<  mask<<  endl;
>     cout<<  "mask>>63 = 0x"<<  hex<<  (mask>>63)<<  endl;
>     cout<<  "mask>>64 = 0x"<<  hex<<  (mask>>64)<<  endl;
>
> I get:
> mask = 0x8000000000000000
> mask>>63 = 0x1
> mask>>64 = 0x8000000000000000
>
> Why is the final value not: 0x0 ?
>

Shifting a 64bit integer 64 times is UB so any value is possible.

/Leigh

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

#7985

On 19/07/2011 17:48, Michael D. Berger wrote:
> With:
> g++ --version
> g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>
> On:
> uname -a
> Linux mbrc40 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686
> i686 i386 GNU/Linux
> (A Centos box)
>
> Running the program:
>     uint64_t    mask = 0x8000000000000000ULL;
>     cout<<  "mask = 0x"<<  hex<<  mask<<  endl;
>     cout<<  "mask>>63 = 0x"<<  hex<<  (mask>>63)<<  endl;
>     cout<<  "mask>>64 = 0x"<<  hex<<  (mask>>64)<<  endl;
>
> I get:
> mask = 0x8000000000000000
> mask>>63 = 0x1
> mask>>64 = 0x8000000000000000
>
> Why is the final value not: 0x0 ?
>
> Thanks for your comments.
> Mike.

Some architectures only use the bottom bits of the shift value.  So it's 
effectively 64 AND 63, AKA zero.

I'd look it up, but the manual is at work...

Andy

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

#7986

Andy Champ wrote:
> On 19/07/2011 17:48, Michael D. Berger wrote:
>> With:
>> g++ --version
>> g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>>
>> On:
>> uname -a
>> Linux mbrc40 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST
>> 2011 i686 i686 i386 GNU/Linux
>> (A Centos box)
>>
>> Running the program:
>>     uint64_t    mask = 0x8000000000000000ULL;
>>     cout<<  "mask = 0x"<<  hex<<  mask<<  endl;
>>     cout<<  "mask>>63 = 0x"<<  hex<<  (mask>>63)<<  endl;
>>     cout<<  "mask>>64 = 0x"<<  hex<<  (mask>>64)<<  endl;
>>
>> I get:
>> mask = 0x8000000000000000
>> mask>>63 = 0x1
>> mask>>64 = 0x8000000000000000
>>
>> Why is the final value not: 0x0 ?
>>
>> Thanks for your comments.
>> Mike.
>
> Some architectures only use the bottom bits of the shift value.  So
> it's effectively 64 AND 63, AKA zero.
>
> I'd look it up, but the manual is at work...
>

The language standard says its undefined, because different hardware 
implement it differently.

The reason for the masking is that actually shifting billions of times 
(mask >> 0xFFFFFFFFFFFFF) would give an awful interrupt latency.


Bo Persson

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

#8005

On Jul 19, 10:52 pm, "Bo Persson" <b...@gmb.dk> wrote:
> Andy Champ wrote:

    [...]
> The language standard says its undefined, because different hardware
> implement it differently.

That's the real reason.  In practice, as has already been
mentionned, a lot of hardware simply ignore all but the bottom n
bits in the shift count.

> The reason for the masking is that actually shifting billions
> of times (mask >> 0xFFFFFFFFFFFFF) would give an awful
> interrupt latency.

You got it right the first time.  If it were defined, the
compiler would probably have to generate an additional test in
the code, but there would be no latency problem (unless there
were something wierd in the hardware).

What it means, of course, is that if the shift count may be more
than the number of bits in an int, you have to explicity write
the test.

--
James Kanze

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

#8019

On Wed, 20 Jul 2011 12:57:51 -0700, James Kanze wrote:

[...]
> 
> What it means, of course, is that if the shift count may be more than
> the number of bits in an int, you have to explicity write the test.

More OR EQUAL. If it were just "more", I wouldn't have had to rewrite
a line or two of code, and would not have posted the original question.

Mike.

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

#8030

"Michael D. Berger" <m_d_berger_1900@yahoo.com>
>> What it means, of course, is that if the shift count may be more than
>> the number of bits in an int, you have to explicity write the test.
>
> More OR EQUAL. If it were just "more", I wouldn't have had to rewrite
> a line or two of code, and would not have posted the original question.

LOL, I ran into the same problem a few months ago. And a few years earlier 
into the other one with (small) negative numbers -- wouldn't it be logical 
that negative shift goes in the opposite direction? ;-))

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

#8054

On 21/07/2011 10:10, Balog Pal wrote:
> wouldn't it be logical that negative shift goes in the opposite direction?

Not if you are a chip designer.  The circuitry used is different. 
Similar, but different.

Andy

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

#8093

On Jul 21, 10:10 am, "Balog Pal" <p...@lib.hu> wrote:
> "Michael D. Berger" <m_d_berger_1...@yahoo.com>

> >> What it means, of course, is that if the shift count may be more than
> >> the number of bits in an int, you have to explicity write the test.

> > More OR EQUAL. If it were just "more", I wouldn't have had to rewrite
> > a line or two of code, and would not have posted the original question.

> LOL, I ran into the same problem a few months ago. And a few years earlier
> into the other one with (small) negative numbers -- wouldn't it be logical
> that negative shift goes in the opposite direction? ;-))

Logically, yes.  There are two arguments: what the language
should require from a logical point of view, and what it should
require to provide the best performance.  In a lot of cases, the
programmer knows that the shift count will be within range, but
the compiler doesn't.  If the language had to enforce more
complicated semantics, it would have to generate extra code to
test for the case which the programmer knows can't occur.  (I'm
not saying that this is necessarily a good argument, but it's
certainly the argument which motivated the current language
specification.)

--
James Kanze

[toc] | [prev] | [standalone]

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

csiph-web