Searching \ for '[PIC] PIC24H: shift left a 32-bit integer (bug?)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC24H: shift left a 32-bit integer (bug?)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC24H: shift left a 32-bit integer (bug?)'
2009\03\23@082928 by Vitaliy

flavicon
face
Say you have this code:

   long int temp;
   int shift;

   shift = 16;

   temp = 0x00000001 << shift;

The value stored in temp is 0x00000000, instead of 0x00010000. Here's the
disassembly:

int main()
26:                {
0AAA6  FA0006     lnk #0x6
27:                  long int temp;
28:                  int shift;
29:
30:                  shift = 16;
0AAA8  200100     mov.w #0x10,0x0000
0AAAA  780F00     mov.w 0x0000,[0x001c]
31:
32:                  temp = 0x00000001 << shift;
0AAAC  200011     mov.w #0x1,0x0002
0AAAE  78001E     mov.w [0x001c],0x0000
0AAB0  DD0800     sl 0x0002,0x0000,0x0000
0AAB2  DE80CF     asr 0x0000,#15,0x0002
0AAB4  980710     mov.w 0x0000,[0x001c+2]
0AAB6  980721     mov.w 0x0002,[0x001c+4]

Even more bizarre is a situation when

 shift = 15;
 temp = 0x00001111;

After the shift, temp is 0xFFFF8000 (this works with any number, 0x00009876
would produce the same result)

If we make shift = 14, we get: 0x00004000.

Is this a known bug in C30?

Finally, a stupid question: how do you display C30 version?

Vitaliy

2009\03\23@085949 by Harold Hallikainen

face
flavicon
face

> Finally, a stupid question: how do you display C30 version?

Run the compiler from the command line with the -v switch.

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\03\23@092340 by Bob Ammerman

picon face
>    long int temp;
>    int shift;
>
>    shift = 16;
>
>    temp = 0x00000001 << shift;
>
> The value stored in temp is 0x00000000, instead of 0x00010000. Here's the
> disassembly:

No bug at all. The value 0x00000001 is an "int", not a "long". You'd avoid
your error with 0x00000001L

-- Bob Ammerman
RAm Systems

2009\03\23@103415 by William \Chops\ Westfield

face picon face

On Mar 23, 2009, at 5:28 AM, Vitaliy wrote:

> Say you have this code:
>
>    long int temp;
>    int shift;
>
>    shift = 16;
>
>    temp = 0x00000001 << shift;

I don't think leading zeros will succeed in making the compiler  
believe that an int is a long.  Try:

   temp = 1L << shift;

BillW

2009\03\23@141050 by Peter Restall

flavicon
face
Date: Mon, 23 Mar 2009 05:28:17 -0700

On Mon, 23 Mar 2009 05:28:17 -0700, Vitality wrote:

{Quote hidden}

Evening Vitality.

I don't think that is a bug - you've specified an int literal, which would be
16 bits I'm presuming.  Try something like:

       temp = 0x00000001l << shift;

Or perhaps even use a 'ul' suffix.  That should prevent the bits falling
off the end, presuming of course that longs are more than 16 bits.

A decent compiler would probably warn about that sort of thing though, so
perhaps that's the real bug :)

Regards,

Pete Restall

2009\03\23@154826 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
{Quote hidden}

Here's
> the
> > disassembly:
> >
> > [snip]
>
> Evening Vitality.
>
> I don't think that is a bug - you've specified an int literal, which
would
> be
> 16 bits I'm presuming.  Try something like:
>
>        temp = 0x00000001l << shift;
>
> Or perhaps even use a 'ul' suffix.  That should prevent the bits
falling
> off the end, presuming of course that longs are more than 16 bits.
>
> A decent compiler would probably warn about that sort of thing though,
so
> perhaps that's the real bug :)


It's not a fixed shift though so unless the compiler added some run time
checking it won't know how many bits the variable is being shifted by.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\23@162751 by Vitaliy

flavicon
face
Bob Ammerman wrote:
>>    long int temp;
>>    int shift;
>>
>>    shift = 16;
>>
>>    temp = 0x00000001 << shift;
>>
>> The value stored in temp is 0x00000000, instead of 0x00010000. Here's the
>> disassembly:
>
> No bug at all. The value 0x00000001 is an "int", not a "long". You'd avoid
> your error with 0x00000001L

D'oh! :-S

Thanks, of course it fixed the problem. I completely forgot about the L on
the end, I'm guessing because in the same code right-shifting a 32-bit value
worked just fine.

Vitaliy

2009\03\23@162901 by Vitaliy

flavicon
face
Michael Rigby-Jones wrote:
> It's not a fixed shift though so unless the compiler added some run time
> checking it won't know how many bits the variable is being shifted by.

FWIW, a fixed shift exhibited the same behavior.


2009\03\24@132404 by Peter Restall

flavicon
face

On Mon, 23 Mar 2009 19:48:17 -0000, Michael Rigby-Jones wrote:

{Quote hidden}

Ah, but an optimising compiler would surely be doing dataflow analysis and
spot that Vitality's code had just set the 'shift' variable just above the
line it was used.  And since the variable is not marked as volatile or with
any other such modifier, it could be a prime candidate for a literal
substitution to save a few opcodes.  Just purely speculating here though,
although DFA is a fairly common technique in the area of optimisations (and
also heavily used to check type safety in compilers for languages like Java
and .NET CLI).  All depends on how sophisticated the compiler is really.

Regards,

Pete Restall

2009\03\24@145552 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu] On
Behalf
{Quote hidden}

though,
> >so
> >> perhaps that's the real bug :)
> >
> >
> > It's not a fixed shift though so unless the compiler added some run
time
> > checking it won't know how many bits the variable is being shifted
by.
> >
> > Regards
> >
> > Mike
>
> Ah, but an optimising compiler would surely be doing dataflow analysis
and
> spot that Vitality's code had just set the 'shift' variable just above
the
> line it was used.  And since the variable is not marked as volatile or
> with
> any other such modifier, it could be a prime candidate for a literal
> substitution to save a few opcodes.  Just purely speculating here
though,
> although DFA is a fairly common technique in the area of optimisations
> (and
> also heavily used to check type safety in compilers for languages like
> Java
> and .NET CLI).  All depends on how sophisticated the compiler is
really.
>

Yes I agree provided the original code snippet represented the only use
of the variables.  Actually I suspect GCC would to optimise this if that
was truly the only points that the shift variable was modified, but then
again why would you use a variable to specify how many bits to shift if
you weren't going to change it?

Cheers

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...