|
I'm trying to get some 'C' code that I prototyped using VC++
(easier to debug) working on a 5416 using CCS v1.21 -- But it doesn't work as expected. Here's the code: typedef unsigned int uint16; typedef unsigned long uint32; /* Simple shift test */ uint16 a; uint32 b; a = 0x3FFF; /* Shift A up into top 16 bits of b */ b = a << 15; b = b << 1; Instead of ending up with 0x3FFF0000 in b I end up with 0x00010000 Stepping thru the assembly it is difficult to see what point this happens at because of the pipeline delay. SXM, OVM are both 0 during the execution of this code. Am I being unusually dense here or ? I prototyped a whole routine in VC++, being careful to keep the type sized the same for uint16 and uint32. So much for 'C' being a portable language, at least where CCS is concerned. Thanks, Brian ----------------- Brian C. Lane (KC7TYU) Programmer www.shinemicro.com RF, DSP & Microcontroller Design |
|
|
CCS shift problems
Started by ●June 13, 2002
Reply by ●June 13, 20022002-06-13
|
Brian, --- In c54x@y..., Brian C. Lane <brian@s...> wrote: > > a = 0x3FFF; > > /* Shift A up into top 16 bits of b */ > b = a << 15; > b = b << 1; > > Instead of ending up with 0x3FFF0000 in b I end up with 0x00010000 a << 15 seems to be calculated as UINT16 which may not be compliant to ANSI standard (not sure). How about explicitly cast the value to UINT32 like this? b = (UINT32)(a << 15); Regards, -- Motohiko Shinozaki () |
Reply by ●June 13, 20022002-06-13
|
My understanding of A<<N is that the shift is done using the size
declared for A. If A is uint16 the shift result will also be uint16. To make the shift use 32-bits, do ((uint32)A)<<N. -- GT ----- Original Message ----- From: "Brian C.Lane" <> To: <> Sent: Thursday, June 13, 2002 12:31 AM Subject: [c54x] CCS shift problems I'm trying to get some 'C' code that I prototyped using VC++ (easier to debug) working on a 5416 using CCS v1.21 -- But it doesn't work as expected. Here's the code: typedef unsigned int uint16; typedef unsigned long uint32; /* Simple shift test */ uint16 a; uint32 b; a = 0x3FFF; /* Shift A up into top 16 bits of b */ b = a << 15; b = b << 1; Instead of ending up with 0x3FFF0000 in b I end up with 0x00010000 Stepping thru the assembly it is difficult to see what point this happens at because of the pipeline delay. SXM, OVM are both 0 during the execution of this code. Am I being unusually dense here or ? I prototyped a whole routine in VC++, being careful to keep the type sized the same for uint16 and uint32. So much for 'C' being a portable language, at least where CCS is concerned. Thanks, Brian ----------------- Brian C. Lane (KC7TYU) Programmer www.shinemicro.com RF, DSP & Microcontroller Design _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://www.yahoogroups.com/group/c54x Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/ |
Reply by ●June 13, 20022002-06-13
|
L_var_out = (Word32) var1 << 16 or u can say since u r porting it on C where does this 54x come into picture ..... u can very well write i like following b=(UINT)a<< 16; why to write it the way u want it to do... i.e y do u ant to write it like b=a<<15 and b=b<<1 i am dead sure that the above code is definately going to work........... thanks sachin On Thu, 13 Jun 2002 Graham Trott wrote : >My understanding of A<<N is that the shift is done using the size >declared >for A. If A is uint16 the shift result will also be uint16. To >make the >shift use 32-bits, do ((uint32)A)<<N. > >-- GT > >----- Original Message ----- > From: "Brian C.Lane" <> >To: <> >Sent: Thursday, June 13, 2002 12:31 AM >Subject: [c54x] CCS shift problems >I'm trying to get some 'C' code that I prototyped using VC++ >(easier >to debug) working on a _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs |
Reply by ●June 13, 20022002-06-13
|
On Wed, 12 Jun 2002 16:31:20 -0700, you wrote: >typedef unsigned int uint16; >typedef unsigned long uint32; > > /* Simple shift test */ > uint16 a; > uint32 b; > > a = 0x3FFF; > > /* Shift A up into top 16 bits of b */ > b = a << 15; > b = b << 1; > Thanks to everyone who responded, several had the right answer <G>. The problem is that a is a 16 bit value and the initial shift up by 15 results in a 16 bit answer (0x8000) which gets stored in the 32 bit result. It then shifts the 0x8000 to a 0x10000. I'm not an expert on the intricacies of C but this seems wrong to me. It ought to be automatically cast to the bitsize of the result it is being stored into. But that's the way the CCS compiler works (I should try this on gcc under Linux to see how it does it too, just for comparison). Anyway, 2 of the right ways to do it are: b = a; b = b << 15; b = b << 1; or: b = (uint32) a << 15; b = b << 1; Thanks again, Brian ----------------- Brian C. Lane (KC7TYU) Programmer www.shinemicro.com RF, DSP & Microcontroller Design |
Reply by ●June 14, 20022002-06-14
|
Hi! Try this b = ((uint32) a) << 15; b = b << 1; Tell me if it works! --emer On 13 Jun 2002 wrote: > Message: 1 > Date: Wed, 12 Jun 2002 16:31:20 -0700 > From: Brian C. Lane <> > Subject: CCS shift problems > > I'm trying to get some 'C' code that I prototyped using VC++ (easier > to debug) working on a 5416 using CCS v1.21 -- But it doesn't work as > expected. Here's the code: > typedef unsigned int uint16; > typedef unsigned long uint32; > > /* Simple shift test */ > uint16 a; > uint32 b; > > a = 0x3FFF; > > /* Shift A up into top 16 bits of b */ > b = a << 15; > b = b << 1; > Instead of ending up with 0x3FFF0000 in b I end up with 0x00010000 > Stepping thru the assembly it is difficult to see what point this > happens at because of the pipeline delay. SXM, OVM are both 0 during > the execution of this code. > > Am I being unusually dense here or ? I prototyped a whole routine in > VC++, being careful to keep the type sized the same for uint16 and > uint32. So much for 'C' being a portable language, at least where CCS > is concerned. > > Thanks, > > Brian > > ----------------- > Brian C. Lane (KC7TYU) Programmer > www.shinemicro.com RF, DSP & Microcontroller Design |
