Reply by Emerson Tan 95-28046●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
Reply by Brian C. Lane●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 sachin p modi●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 Graham Trott●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:
--- 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 Brian C. Lane●June 13, 20022002-06-13
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