Forums

Multiple inline Assembler-Commands with IAR Embedded Workbench for MSP430?

Started by Bastian Stahmer April 6, 2005
Hello!

I want to execute multiple inline-assembler-commandos one after 
another, so i tried it this way:

asm("push R4\n"
	"push R4\n");

with the ICC430-Suite everything worked fine but the IAR Embedded 
Workbench says "Multiple lines not allowed in inline-assembler"

Is there a trick how to have more than one instruction in one 
"asm("");"-Instruction?


Thank you in advance,


Bastian Stahmer

Bastian Stahmer wrote:

> Hello! > > I want to execute multiple inline-assembler-commandos one after another, > so i tried it this way: > > asm("push R4\n" > "push R4\n"); > > with the ICC430-Suite everything worked fine but the IAR Embedded > Workbench says "Multiple lines not allowed in inline-assembler" > > Is there a trick how to have more than one instruction in one > "asm("");"-Instruction?
What do you gain from it beside confusion ? Multiple commands are reserved for parallel processing, such as in a DSP where you can this way define what happens at the same time. Within the tight limits of the cpu of course. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Rene Tschaggelar wrote:

> What do you gain from it beside confusion ? > Multiple commands are reserved for parallel processing, > such as in a DSP where you can this way define what > happens at the same time. Within the tight limits of > the cpu of course.
What??? Way off base! The poster is asking how to insert multiple (sequential) instructions into a single in-line assembler statement, rather than have to use asm("") on every line. Regards, Mark
You need to read the compiler manual. Try looking up the #pragma
instruction.

Mark McDougall wrote:
> Rene Tschaggelar wrote: > >> What do you gain from it beside confusion ? >> Multiple commands are reserved for parallel processing, >> such as in a DSP where you can this way define what >> happens at the same time. Within the tight limits of >> the cpu of course. > > What??? Way off base! > > The poster is asking how to insert multiple (sequential) instructions > into a single in-line assembler statement, rather than have to use > asm("") on every line.
When I was young and foolish I took advantage of such capabilities in various assemblers etc. The principal result was non-portable source. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
CBFalconer wrote:

> When I was young and foolish I took advantage of such capabilities in > various assemblers etc. The principal result was non-portable > source.
I can imagine why the poster is asking - during development it would be a right royal pain in the butt to have every assembler instruction wrapped with asm(""), particularly for lengthy inline routines. As for non-portability, IMHO being able to enter "free-format" inline assembler routines would be much preferable; aside from the fact that most in-line assembler that one writes is going to be restricted to the one development environment, should porting be required the problem can easily be overcome in a few minutes using a decent text editor with macro abilities. Regards, Mark
Mark McDougall <markm@vl.com.au> wrote:
> CBFalconer wrote:
> > When I was young and foolish I took advantage of such capabilities in > > various assemblers etc. The principal result was non-portable > > source.
> I can imagine why the poster is asking - during development it would be > a right royal pain in the butt to have every assembler instruction > wrapped with asm(""), particularly for lengthy inline routines.
You've spotted the problem, but IMHO deduced the wrong solution. Inline-asm routines (as opposed to code blocks) have no business of being lengthy. If they're long enough that even slights hurts writing them inline, the right response is to move them into separate assembly source files. The only real reason to favour inline assembly routines over separate assembly modules is to give the compiler opportunity to inline them instead of calling, avoiding call overhead. Once the routine becomes lengthy, that's no longer worth bothering with. Asm code blocks inside ordinary C or C++ functions can be a different matter. They may still make sense even if they're longish, but it takes some serious effort on the side of the C implementor to avoid losing performance to border conflicts between C and asm than can possibly be gained by the assembly code. Allowing multi-statement assembly fragments is only the first small step toward that goal. The fact that inline assembly is non-portable is obvious. It can still be worth it *if* the tools are up to the task. It may even be a necessity in cases where the task at hand can't be expressed sensibly in C, e.g. because it needs access to the carry flag. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Hans-Bernhard Broeker wrote:
> Mark McDougall <markm@vl.com.au> wrote: >> CBFalconer wrote: > >>> When I was young and foolish I took advantage of such >>> capabilities in various assemblers etc. The principal result >>> was non-portable source. > >> I can imagine why the poster is asking - during development it >> would be a right royal pain in the butt to have every assembler >> instruction wrapped with asm(""), particularly for lengthy inline >> routines. > > You've spotted the problem, but IMHO deduced the wrong solution. > Inline-asm routines (as opposed to code blocks) have no business > of being lengthy. If they're long enough that even slights hurts > writing them inline, the right response is to move them into > separate assembly source files. The only real reason to favour > inline assembly routines over separate assembly modules is to > give the compiler opportunity to inline them instead of calling, > avoiding call overhead. Once the routine becomes lengthy, that's > no longer worth bothering with.
No, I claim that it is to handle some sort of non-portable or speed critical condition, and that the assembly portion should be short and isolated in a suitable non-portable module anyway.
>
... snip ...
> > The fact that inline assembly is non-portable is obvious. It can > still be worth it *if* the tools are up to the task. It may even be a > necessity in cases where the task at hand can't be expressed sensibly > in C, e.g. because it needs access to the carry flag.
In the original case of which I spoke it wasn't a machine portability problem, but an assembler problem. Different assemblers just didn't have the multiple instruction per line facility, but most could handle straightforward code. The same problem applies when the assembly usage is buried in a C source. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson