In asm this is even smaller/faster:_

       swpb   R15
       MOV.B   r15,r14  OR and.b  #-1,r15

Since asm doesn't understand 32 bit values there is no need to 
explicitly clear the MSW, your code simply works on the MSW, ignoring 
the LSW for this instant, however the question was about C. In C your 
compiler could, of course declare a union and do the same, building the 
value from a 32 bit data type, then calculating using only the upper 16 
bit data type, but that would be expecting too much.

Al

Paul Curtis wrote:

>All, 
>
>  
>
>>>... If
>>>you're trying to divide a 32 bit value by 65536, in the 
>>>      
>>>
>>second case,  
>>    
>>
>>>it would be quicker to simply move the MSW into the LSW, in 
>>>      
>>>
>>the first 
>>    
>>
>>>case you move MSW to LSW, byte swap using SWPB, then and the result 
>>>with 0x00FFH. Of course SWPB isn't C, but it's a damned 
>>>      
>>>
>>sight quicker 
>>    
>>
>>>than a chain of shifts.
>>>
>>>Al
>>>      
>>>
>>I would hope that most aq430 C compilers emit exactly the 
>>code you suggest for a long unsigned right shift by 24! The 
>>AQ430 C compiler does, anyway.
>>    
>>
>
>No, that's too slow by two words:
>
>  mov.w r15, r14  ; shift by 16
>  mov.w #0, r15   ; clear vacated bits
>  swpb  r14       ; shift by 8
>  and.w #255, r14 ; clear vacated bits
>
>This is 5 words.  Ok, can make it a little better:
>
>  mov.w r15, r14  ; shift by 16
>  mov.w #0, r15   ; clear vacated bits
>  swpb  r14       ; shift by 8
>  and.b #-1, r14  ; clear vacated bits
>
>Four words.  Still not good enough!
>
>  swpb  r15
>  mov.b r15, r14
>  mov.w #0, r15
>
>You gotta know your processor...  Of course, CrossWorks generates the
>last and even EW430 catches it.  :-)
>
>--
>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

That's one for you compiler guys. If I were to write in C I would 
construct my code to force this translation if the compiler didn't do it 
anyway. thhis is where compilers can get VERY complex though (Hi Alex 
;?} )There are potentially so many of these optimisations that it would 
be difficult for any compiler to 'know' them all.

Al

Preston Gurd wrote:

>
>  
>
>>... If 
>>you're trying to divide a 32 bit value by 65536, in the second
case,  it 
>>would be quicker to simply move the MSW into the LSW, in the first case 
>>you move MSW to LSW, byte swap using SWPB, then and the result with 
>>0x00FFH. Of course SWPB isn't C, but it's a damned sight
quicker than a 
>>chain of shifts.
>>
>>Al
>>    
>>
>
>I would hope that most aq430 C compilers emit exactly the code you suggest
>for a long unsigned right shift by 24! The AQ430 C compiler does, anyway.
>
>Preston Gurd
>(the AQ430 C compiler guy)
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

Thanks, Paul!

Preston

> 
>   swpb  r15
>   mov.b r15, r14
>   mov.w #0, r15
> 
> You gotta know your processor...  Of course, CrossWorks generates the
> last and even EW430 catches it.  :-)
> 

All, 

> > ... If
> > you're trying to divide a 32 bit value by 65536, in the 
> second case,  
> > it would be quicker to simply move the MSW into the LSW, in 
> the first 
> > case you move MSW to LSW, byte swap using SWPB, then and the result 
> > with 0x00FFH. Of course SWPB isn't C, but it's a damned 
> sight quicker 
> > than a chain of shifts.
> > 
> > Al
> 
> I would hope that most aq430 C compilers emit exactly the 
> code you suggest for a long unsigned right shift by 24! The 
> AQ430 C compiler does, anyway.

No, that's too slow by two words:

  mov.w r15, r14  ; shift by 16
  mov.w #0, r15   ; clear vacated bits
  swpb  r14       ; shift by 8
  and.w #255, r14 ; clear vacated bits

This is 5 words.  Ok, can make it a little better:

  mov.w r15, r14  ; shift by 16
  mov.w #0, r15   ; clear vacated bits
  swpb  r14       ; shift by 8
  and.b #-1, r14  ; clear vacated bits

Four words.  Still not good enough!

  swpb  r15
  mov.b r15, r14
  mov.w #0, r15

You gotta know your processor...  Of course, CrossWorks generates the
last and even EW430 catches it.  :-)

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

> 
> ... If 
> you're trying to divide a 32 bit value by 65536, in the second case, 
it 
> would be quicker to simply move the MSW into the LSW, in the first case 
> you move MSW to LSW, byte swap using SWPB, then and the result with 
> 0x00FFH. Of course SWPB isn't C, but it's a damned sight quicker
than a 
> chain of shifts.
> 
> Al

I would hope that most aq430 C compilers emit exactly the code you suggest
for a long unsigned right shift by 24! The AQ430 C compiler does, anyway.

Preston Gurd
(the AQ430 C compiler guy)

 
I'm sorry, this is far too painful for me to watch unraveling.

Just because #define preprocessor calculations are evaluated to 
32bits on ALL IAR compiler's doesn't mean to say a C-integer is 
necessarily 32bits. Depending upon the target architecture, C-
integers are sometimes 16bit and sometimes 32bits. For MSP430 the 
register size is 16bits so the size of an integer will be 16bits on 
all MSP430 compilers.

PS You can use the IAR intrinsic function (one assembler instruction)
unsigned short __swap_bytes(unsigned short);
from within C-langauage to shift data up or down 8 bits at a time.
Don't forget to MASK and OR the result back together again.

Hope this helps.

Colin,

--- In msp430@msp4..., Onestone <onestone@b...> wrote:
> Exactly what I said. IAR does support 32 bit
values but YOU have 
to 
> declare them as such. RTFM
> 
> Al
> 
> Bharat Kumar.V wrote:
> 
> > 
> >
> >Hi,
> >
> >Thanks for ur reply
> >
> > 
> >
> >Actually I have a code(Encryption algorithm) working on PC.
> >
> >Now I am trying port the same code on msp430  using IAR.
> >
> >I think that IAR C compiler supports 32 bit compilation.
> >
> >So I thought that the same code which was working on 32 bit 
processor
> >would work fine.
> >
> >I am getting warnings which I told earlier.
> >
> >Can any body tell me what I am doing is right or wrong. 
> >
> > 
> >
> >B
> >
> >-----Original Message-----
> >From: msp430@msp4... [mailto:msp430@msp4...] On 
Behalf
> >Of Onestone
> >Sent: Thursday, July 14, 2005 2:44 PM
> >To: msp430@msp4...
> >Subject: Re: [msp430] SHIFT OPERATION IN 'C' PROGRAM COMPILED
BY 
IAR
> >COMPILER
> >
> > 
> >
> >You're trying to shift a 16 bit value by 24 or 16 bits? Of course 
the 
> >compiler will complain. If you read the
compiler manual first it 
will 
> >tell you the size of the default  types. The
compiler probably 
supports 
> >the shifting, but you'll have to use it
on  a long integer. What 
on 
> >earth are you trying to achieve? Engage your
brain and think 
about it 
> >for a minute or two. You are just assuming
that a shift will be 
the 
> >quick way to do this (either that or you
don't understand whjat 
you're 
> >doing. There comes a point when shifting is no
longer efficient. 
If 
> >you're trying to divide a 32 bit value by
65536, in the second 
case,  it
> >
> >would be quicker to simply move the MSW into the LSW, in the 
first case 
> >you move MSW to LSW, byte swap using SWPB,
then and the result 
with 
> >0x00FFH. Of course SWPB isn't C, but
it's a damned sight quicker 
than a 
> >chain of shifts.
> >
> >Al
> >
> >Bharat Kumar.V wrote:
> >
> >  
> >
> >>Hi,
> >>
> >>
> >>
> >>I am using shift in my C program (>>24, >>16)
> >>
> >>My program is giving me warning saying that "shift count is
too 
large".
> >>
> >>Does this IAR compiler support that shifting?
> >>
> >>Please give some suggestion on this. 
> >>
> >>Regards,
> >>
> >>
> >>
> >>B
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>.
> >>
> >>
> >>>  Terms of Service. 
> >
> > 
> >
> >  _____  
> >
> >
> >
> >
> >
> >
> >
> >.
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >
> >
> >  
> >

Exactly what I said. IAR does support 32 bit values but YOU have to 
declare them as such. RTFM

Al

Bharat Kumar.V wrote:

> 
>
>Hi,
>
>Thanks for ur reply
>
> 
>
>Actually I have a code(Encryption algorithm) working on PC.
>
>Now I am trying port the same code on msp430  using IAR.
>
>I think that IAR C compiler supports 32 bit compilation.
>
>So I thought that the same code which was working on 32 bit processor
>would work fine.
>
>I am getting warnings which I told earlier.
>
>Can any body tell me what I am doing is right or wrong. 
>
> 
>
>B
>
>-----Original Message-----
>From: msp430@msp4... [mailto:msp430@msp4...] On Behalf
>Of Onestone
>Sent: Thursday, July 14, 2005 2:44 PM
>To: msp430@msp4...
>Subject: Re: [msp430] SHIFT OPERATION IN 'C' PROGRAM COMPILED BY
IAR
>COMPILER
>
> 
>
>You're trying to shift a 16 bit value by 24 or 16 bits? Of course the 
>compiler will complain. If you read the compiler manual first it will 
>tell you the size of the default  types. The compiler probably supports 
>the shifting, but you'll have to use it on  a long integer. What on 
>earth are you trying to achieve? Engage your brain and think about it 
>for a minute or two. You are just assuming that a shift will be the 
>quick way to do this (either that or you don't understand whjat
you're 
>doing. There comes a point when shifting is no longer efficient. If 
>you're trying to divide a 32 bit value by 65536, in the second case, 
it
>
>would be quicker to simply move the MSW into the LSW, in the first case 
>you move MSW to LSW, byte swap using SWPB, then and the result with 
>0x00FFH. Of course SWPB isn't C, but it's a damned sight quicker
than a 
>chain of shifts.
>
>Al
>
>Bharat Kumar.V wrote:
>
>  
>
>>Hi,
>>
>>
>>
>>I am using shift in my C program (>>24, >>16)
>>
>>My program is giving me warning saying that "shift count is too
large".
>>
>>Does this IAR compiler support that shifting?
>>
>>Please give some suggestion on this. 
>>
>>Regards,
>>
>>
>>
>>B
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>.
>>
>>
>>>  Terms of Service. 
>
> 
>
>  _____  
>
>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

I would look into the definition of variabl;e types between the two 
compilers. Sounds like the "int" type for the 32 bit processor was 
32 bits longs, whereas it is 16 bits long for MSP430.

Michel

--- In msp430@msp4..., "Bharat Kumar.V" <bharatv@e...> wrote:
>  
> 
> Hi,
> 
> Thanks for ur reply
> 
>  
> 
> Actually I have a code(Encryption algorithm) working on PC.
> 
> Now I am trying port the same code on msp430  using IAR.
> 
> I think that IAR C compiler supports 32 bit compilation.
> 
> So I thought that the same code which was working on 32 bit 
processor
> would work fine.
> 
> I am getting warnings which I told earlier.
> 
> Can any body tell me what I am doing is right or wrong. 
> 
>  
> 
> B
> 
> -----Original Message-----
> From: msp430@msp4... [mailto:msp430@msp4...] On 
Behalf
> Of Onestone
> Sent: Thursday, July 14, 2005 2:44 PM
> To: msp430@msp4...
> Subject: Re: [msp430] SHIFT OPERATION IN 'C' PROGRAM COMPILED BY 
IAR
> COMPILER
> 
>  
> 
> You're trying to shift a 16 bit value by 24 or 16 bits? Of course 
the 
> compiler will complain. If you read the compiler
manual first it 
will 
> tell you the size of the default  types. The
compiler probably 
supports 
> the shifting, but you'll have to use it on  a
long integer. What 
on 
> earth are you trying to achieve? Engage your brain
and think about 
it 
> for a minute or two. You are just assuming that a
shift will be 
the 
> quick way to do this (either that or you
don't understand whjat 
you're 
> doing. There comes a point when shifting is no
longer efficient. 
If 
> you're trying to divide a 32 bit value by
65536, in the second 
case,  it
> 
> would be quicker to simply move the MSW into the LSW, in the first 
case 
> you move MSW to LSW, byte swap using SWPB, then
and the result 
with 
> 0x00FFH. Of course SWPB isn't C, but
it's a damned sight quicker 
than a 
> chain of shifts.
> 
> Al
> 
> Bharat Kumar.V wrote:
> 
> >Hi,
> >
> > 
> >
> >I am using shift in my C program (>>24, >>16)
> >
> >My program is giving me warning saying that "shift count is too 
large".
> >
> >Does this IAR compiler support that shifting?
> >
> >Please give some suggestion on this. 
> >
> >Regards,
> >
> > 
> >
> >B
> >
> > 
> >
> >
> >
> >
> >
> >
> >
> >.
> >
> > 
> >>  Terms of Service. 
> 
>  
> 
>   _____  
> 
> 
> 
> 

Which type of variable are you trying to shift? If it's 16 bits or 
less, there are faster ways to accomplish that shift!

Michel

--- In msp430@msp4..., "Bharat Kumar.V" <bharatv@e...> wrote:
> Hi,
> 
>  
> 
> I am using shift in my C program (>>24, >>16)
> 
> My program is giving me warning saying that "shift count is too 
large".
> 
> Does this IAR compiler support that shifting?
> 
> Please give some suggestion on this. 
> 
> Regards,
> 
>  
> 
> B
> 
>  
> 
> 
> 
> 

You're trying to shift a 16 bit value by 24 or 16 bits? Of course the 
compiler will complain. If you read the compiler manual first it will 
tell you the size of the default  types. The compiler probably supports 
the shifting, but you'll have to use it on  a long integer. What on 
earth are you trying to achieve? Engage your brain and think about it 
for a minute or two. You are just assuming that a shift will be the 
quick way to do this (either that or you don't understand whjat you're

doing. There comes a point when shifting is no longer efficient. If 
you're trying to divide a 32 bit value by 65536, in the second case,  it 
would be quicker to simply move the MSW into the LSW, in the first case 
you move MSW to LSW, byte swap using SWPB, then and the result with 
0x00FFH. Of course SWPB isn't C, but it's a damned sight quicker than
a 
chain of shifts.

Al

Bharat Kumar.V wrote:

>Hi,
>
> 
>
>I am using shift in my C program (>>24, >>16)
>
>My program is giving me warning saying that "shift count is too
large".
>
>Does this IAR compiler support that shifting?
>
>Please give some suggestion on this. 
>
>Regards,
>
> 
>
>B
>
> 
>
>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>