Post by thread:RE: [PIC] PIC24H: shift left a 32-bit integer (bug

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

Date: Mon, 23 Mar 2009 05:28:17 -0700 On Mon, 23 Mar 2009 05:28:17 -0700, Vitality wrote: {Quote hidden}> 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: > > [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 :) Regards, Pete Restall

> -----Original Message----- > From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu] On Behalf {Quote hidden}> Of Peter Restall > Sent: 23 March 2009 18:07 > To: piclistKILLspammit.edu > Subject: Re: [PIC] PIC24H: shift left a 32-bit integer (bug?) > > Date: Mon, 23 Mar 2009 05:28:17 -0700 > > On Mon, 23 Mar 2009 05:28:17 -0700, Vitality wrote: > > > 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: > > > > [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. =======================================================================

On Mon, 23 Mar 2009 19:48:17 -0000, Michael Rigby-Jones wrote: {Quote hidden}>> [snip] >> 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 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

> -----Original Message----- > From: .....piclist-bouncesKILLspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu] On Behalf {Quote hidden}> Of Peter Restall > Sent: 24 March 2009 16:57 > To: piclistspam_OUTmit.edu > Subject: RE: [PIC] PIC24H: shift left a 32-bit integer (bug?) > > > On Mon, 23 Mar 2009 19:48:17 -0000, Michael Rigby-Jones wrote: > > >> [snip] > >> 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 > > 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. =======================================================================