I am appealing to the MSP gcc experts on this one. I am porting code written for IAR to CCE. There is a line of inline assembly:

asm("mov.w #HostCommands,10(SP)");

This produces a compiler error of "illegal mnemonic". I assume that CCE (gcc) wants inline assembly in a different format.

Thanks for the help.

Rich

Start a New Thread

Richard wrote:
> I am appealing to the MSP gcc experts on this one. I am porting code written for IAR to CCE. There is a line of inline assembly:
>
> asm("mov.w #HostCommands,10(SP)");
>
> This produces a compiler error of "illegal mnemonic". I assume that CCE (gcc) wants inline assembly in a different format.
>
CCE doesn't use GCC as its compiler. Gee, this is really simple in
CrossWorks and doesn't use any assembly code. I assume you're porting
that RF stack thing (not SimpliciTI, I don't think)... And, BTW,
CrossWorks identifies a genuine error in that particular code...

Regards,

-- Paul.
Start a New Thread

Sorry about the off topic, but is there an available port anyone has made up for SimpliciTI for CrossWorks? I really like CrossWorks ARM and am considering CrossWorks MSP430 to play with some simple RF network stuff. Currently I'm using CCE and staying under the 16k limit.

I did a bit of Googling, but didn't find anything.

Mark Higgins

----- Original Message -----
From: Paul Curtis
To: m...
Sent: Tuesday, May 26, 2009 5:38 PM
Subject: Re: [msp430] IAR vs CCE Inline Assembly

Richard wrote:
> I am appealing to the MSP gcc experts on this one. I am porting code written for IAR to CCE. There is a line of inline assembly:
>
> asm("mov.w #HostCommands,10(SP)");
>
> This produces a compiler error of "illegal mnemonic". I assume that CCE (gcc) wants inline assembly in a different format.
>
CCE doesn't use GCC as its compiler. Gee, this is really simple in
CrossWorks and doesn't use any assembly code. I assume you're porting
that RF stack thing (not SimpliciTI, I don't think)... And, BTW,
CrossWorks identifies a genuine error in that particular code...

Regards,

-- Paul.



Start a New Thread

Hi,

> Sorry about the off topic, but is there an available port anyone has made
> up for SimpliciTI for CrossWorks? I really like CrossWorks ARM and am
> considering CrossWorks MSP430 to play with some simple RF network stuff.
> Currently I'm using CCE and staying under the 16k limit.

SimpliciTI is quite easy to compile with CrossWorks--I did it in an hour or
so. The worst thing is the directory setup they use.

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

Start a New Thread

There I go making assumptions. OK Paul, I have been pleased with your tools in the past. Perhaps I will go with Rowley this time. IAR is probably NOT an option.
Could you explain how you handle this "context switch" that they are doing with the inline assembly?
A private email would be fine.

rich

--- In m..., Paul Curtis wrote:
>
> Richard wrote:
> > I am appealing to the MSP gcc experts on this one. I am porting code written for IAR to CCE. There is a line of inline assembly:
> >
> > asm("mov.w #HostCommands,10(SP)");
> >
> > This produces a compiler error of "illegal mnemonic". I assume that CCE (gcc) wants inline assembly in a different format.
> >
> CCE doesn't use GCC as its compiler. Gee, this is really simple in
> CrossWorks and doesn't use any assembly code. I assume you're porting
> that RF stack thing (not SimpliciTI, I don't think)... And, BTW,
> CrossWorks identifies a genuine error in that particular code...
>
> Regards,
>
> -- Paul.
>

Start a New Thread

Hi Rich,

If it's the software I'm thinking of, in the file "host.c" add:

// Under-the-hood for CrossWorks...
#include
__va_list __va_base(int); // intrinsic
#pragma intrinsic(__va_base)
typedef void (*void_function_t)(void);

And then change:

asm("mov.w #HostCommands,10(SP)");

to:

*(void_function_t *)(__va_base(0)) = HostCommands;

This compiles to what you require and doesn't need that magic "10". If you
change the software, the 10 may need to be changed in IAR/CCE, but the
compiler works it out for you using this technique.

If Anders would like to propose an intrinsic to overwrite a function or
interrupt function's return address (bletch!) then I will implement it also
so software can be portable. And TI can tag along at some point.

Regards,

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

> -----Original Message-----
> From: m... [mailto:m...] On Behalf Of
> Richard
> Sent: 27 May 2009 20:32
> To: m...
> Subject: [msp430] Re: IAR vs CCE Inline Assembly
>
> There I go making assumptions. OK Paul, I have been pleased with your
> tools in the past. Perhaps I will go with Rowley this time. IAR is
> probably NOT an option.
> Could you explain how you handle this "context switch" that they are doing
> with the inline assembly?
> A private email would be fine.
>
> rich
>
> --- In m..., Paul Curtis wrote:
> >
> > Richard wrote:
> > > I am appealing to the MSP gcc experts on this one. I am porting code
> written for IAR to CCE. There is a line of inline assembly:
> > >
> > > asm("mov.w #HostCommands,10(SP)");
> > >
> > > This produces a compiler error of "illegal mnemonic". I assume that
> CCE (gcc) wants inline assembly in a different format.
> > >
> > CCE doesn't use GCC as its compiler. Gee, this is really simple in
> > CrossWorks and doesn't use any assembly code. I assume you're porting
> > that RF stack thing (not SimpliciTI, I don't think)... And, BTW,
> > CrossWorks identifies a genuine error in that particular code...
> >
> > Regards,
> >
> > -- Paul.
> >
> Start a New Thread

Paul Curtis wrote:
> If Anders would like to propose an intrinsic to overwrite a function or
> interrupt function's return address (bletch!) then I will implement it also
> so software can be portable. And TI can tag along at some point.

That will only happen if somebody can provide me with a real-world use
case that can't be implemented using normal code... Personally, I think
they will be hard to find.

I agree with Paul, the "10" in the original code should act as a warning
signal, as it might change as code is updated, when changing the
compiler settings, or between compiler versions.

We had a similar situation some years ago when people were trying to
modify the content of the stack, so that the processor would enter
low-power mode when returning from an interrupt routine. This resulted
in the introduction of intrinsics like __bis_SR_register_on_exit.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Start a New Thread