I think you don't get the error message because you use gcc3, and the
corresponding code in gcc3 (gcc/stmt.c:expand_asm_operands) only complains
if the value is used as an output. In gcc4
(gcc/gimplify.c:gimplify_asm_expr), the test is refined and an error
produced when the integer value is used as an input as well. Which is good,
if the original source generated undesired code under gcc3.
I had no problems duplicating the problem; PORT1_VECTOR was properly
defined.
Peter
On Thu, Jun 17, 2010 at 1:40 PM, JMGross <msp...@grossibaer.de> wrote:
>
>
> Sure you're right.
> But I wonder why he got an error while I don't.
> I looked at the generated code and the compiler generated a constant
> containing the value (PORT1_VECTOR-512), and the branch brances onto the
> location pointed to by this constant.
> Of course this isn't what was intended, but it produces no error on my
> system. The compiler generates an lvalue. And since it is an input an dnot
> an output parameter, the 'lvalue' may be constant too.
>
> here's the example:
>
> #define VECTOR_OFFSET (-512)
> interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
> asm("br %[add]" :: [add] "m" (PORT1_VECTOR + VECTOR_OFFSET));
> }
>
> 1659 .stabs "j:r(0,4)",64,0,204,11
> 1660 .stabn 192,0,0,.LBB25-testThread3
> 1661 .stabn 224,0,0,.LBE25-testThread3
> 1662 .Lscope8:
> 1663 .stabs "",36,0,0,.Lscope8-testThread3
> 1664 .p2align 1,0
> 1665 .LC17:
> 1666 0840 5EFE .short -418
> 1667 .p2align 1,0
> 1668 .stabs "PORT1SR:F(0,20)",36,0,218,PORT1SR
> 1669 .global PORT1SR
> 1670 .global vector_ffde
> 1671 .type PORT1SR,@function
> 1672 /***********************
> 1673 * Interrupt Service Routine `PORT1SR' at 0xffde
> 1674 ***********************/
> 1675 vector_ffde:
> 1676 PORT1SR:
> 215:ez3.c ****
> 216:ez3.c ****
> 217:ez3.c **** #define VECTOR_OFFSET (-512)
> 218:ez3.c **** interrupt (PORT1_VECTOR) __attribute((naked))
> PORT1SR (void) {
> 1677 .stabn 68,0,218,.LM198-PORT1SR
> 1678 .LM198:
> 1679 /* prologue: naked */
> 1680 .L__FrameSize_PORT1SR=0x0
> 219:ez3.c **** asm("br %[add]" :: [add] "m" (PORT1_VECTOR +
> VECTOR_OFFSET));
> 1681 .stabn 68,0,219,.LM199-PORT1SR
> 1682 .LM199:
> 1683 /* #APP */
> 1684 0842 1042 0000 br &.LC17
> 220:ez3.c **** }
> 1685 .stabn 68,0,220,.LM200-PORT1SR
> 1686 .LM200:
> 1687 /* #NOAPP */
> 1688
> 1689 /* epilogue: naked */
> 1690 .Lfe10:
> 1691 .size PORT1SR,.Lfe10-PORT1SR
> 1692 /********* End of function ******/
>
> Of course that's not what was wanted. Using the 'i' constraint instead of
> the 'm' constraint had had the same result, just without the additional
> memory constant:
> 1681 0840 1042 5EFE br #llo(-418)
>
>
> With your modification, the compiler generates
>
> 1681 0840 1042 5EFE br &-418
>
> which is the intended result.
>
> I still wonder why he got an error message. Maybe PORT1_VECTOR was unknown,
> in addition to the wrong addressing mode/parameter type.
>
>
> JMGross
>
> ----- Ursprüngliche Nachricht -----
> Von: Peter Bigot
> An: GCC for MSP430 - http://mspgcc.sf.net
> Gesendet am: 16.Juni.2010 22:02:52
> Betreff: Re: [Mspgcc-users] memory input 0 is not directly addressable
>
>
> The value of PORT1_VECTOR + VECTOR_OFFSET is an integer, which is not the
> same as an addressable memory location. In gcc4, the parameter to a memory
> reference has to be an lvalue.
>
> Try something like:
>
> asm("br %[add]" :: [add] "m" (*(uint16_t*)(PORT1_VECTOR +
> VECTOR_OFFSET)));
>
>
> Peter
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
