Compiler/MSP430FR5969: bit shift causing compiler warning

Hello EmbeddedMike,

What compiler version are you using?

I tried what you had and all work except:

uint16_t * end_addr   = (uint16_t *)((0x0f00 << 4) & 0xffff);  Warning #69-D integer conversion resulted in a change of sign

so I added cast to fix that

uint16_t * end_addr   = (uint16_t *)((uint16_t)(0x0f00 << 4) & 0xffff);

But that doesn't address the fact that for you the first three versions generate a warning.

Thanks for the quick response. My compiler version: msp430-gcc-7.3.2.154

I suspect that you are compiling with option -mlarge which makes pointers 20 bits. Since integer constants are 16 bits that triggers the warning unless you use a 32 bit constant: (0x0f00L << 4).

Why it fails to issue a warning for the last case I cannot explain. Some subtle difference in the parser between a simple constant and more complex expression perhaps.

No, I tried both small and large memory model, but now I see you are using MSP430-GCC compiler.

Let me dig a little deeper on this.

You're the man. Adding the "U" suffix to the constant prevented the compiler warning. I'll mark this thread as resolved because this answer satisfies my original question.

I abstracted a bit of the problem away in order to focus on the shifting aspect. In my actual project I'm trying to use the register value of MPUSEGB1 because I'd like to avoid having magic numbers. Since I can't append a "U" to a variable I can't use this solution as is. I tried to do something equivalent:

uint16_t * end_addr   = (uint16_t *)(((uint16_t)MPUSEGB1) << 4);

By casting MPUSEGB1 to unsigned integer I expected that the shift would not be treated as an overflow but I'm still getting the warning. Similarly, assigning to an unsigned int first and then shifting also produces the warning:

uint16_t rom_end = MPUSEGB1;
uint16_t * end_addr   = (uint16_t *)(rom_end << 4);

Is there anyway to avoid this warning when using variables?

That's perfect. I really appreciate your help, excellent as always.

I would cast it to the 20 bit type before shifting since segment boundaries can be in upper FRAM.

  end_addr = (uint16_t *)(((__int20)MPUSEGB1)<<4);

But the code generated is not good considering that a movx.w and rlam.a would do the job.

    4514:       40 18 1c 42     movx.w  &0x005a6,r12    ;
    4518:       a6 05 

0000451a <.Loc.6.1>:
    451a:       00 18 4d 4c     movx.a  r12,    r13     ;
    451e:       0c 4c           mov     r12,    r12     ;
    4520:       0f 18 4d 11     rpt #16 { rrax.a        r13             ;
    4524:       b0 13 8e 45     calla   #17806          ;0x0458e

00004528 <.Loc.7.1>:
}
    4528:       0d 12           push    r13             ;
    452a:       0c 12           push    r12             ;
    452c:       0c 16           popm.a  #1,     r12     ;20-bit words

That rips the 20 bit int into two 16 bit pieces before calling a utility routine to shift the 32 bit value 4 places. Then turns it back into a 20 bit register value. Ugh.

Fortunately for my case, MPUSEGB1 will always be in lower FRAM but I think this is a good point. Unless I'm misunderstanding, you seem concerned that shifting first would push the top 4 bits out of the 16 bit uint which would result in a data loss if the border address is in high FRAM (MPUSEGx = 0x1200 for instance).

That lead me to wonder, where do the top bits go when you shift? Functionally I always think of them just "disappearing" but how does that actually work in memory? Is there a standard way to handle bit shifting or does it depend on hardware implementations?

The msb usually goes into a carry bit. (See instruction set description for details.) Very handy if you need to shift something larger than one word. Not visible to C code of course.

With instructions that shift by more than one bit, all but one bit that gets shifted out will be lost.

This function should do the job without all of that conversion to 32 bits and back nonsense:

void *test(void)
{
  asm("movx.w &MPUSEGB1,r12");
  asm("rlam.a #4,r12");
}

David Schultz36 said:

I would cast it to the 20 bit type before shifting since segment boundaries can be in upper FRAM.

  end_addr = (uint16_t *)(((__int20)MPUSEGB1)<<4);

Nice spot. It seems that shift arguments will get promoted up to an int before shifting, but not beyond that, even if the lvalue is larger than an int.

I think I've spotted a gap in the MSP430 GCC backend that could address the poor code being generated. I'm out of the office for a week, but will take a look once I get back.

Thanks,

It would certainly be nice if the compiler better supported the __int20 type. Those conversions to 32 bits and back are painful to read.

I looked through the GCC user guide (SLAU646e) and found no mention of this type so perhaps that should be updated as well.

Hello EmbeddedMike,

I haven’t heard from you for a couple of days now, so I’m assuming you have your answer and are moving forward with your project.
If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

Also, I would like to thank everyone who has contributed to this posting.  Your responses have been very helpful and informative. This is great example of community support.