Multiple inline Assembler-Commands with IAR Embedded Workbench for MSP430?
Apr 06, 2005 7 Replies
B
Bastian Stahmer
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
Didn't find your answer? Ask the community — no account required.
R
Rene Tschaggelar
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.
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
C
cbarn24050
You need to read the compiler manual. Try looking up the #pragma instruction.
C
CBFalconer
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
M
Mark McDougall
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
H
Hans-Bernhard Broeker
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.
C
CBFalconer
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 ...
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
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.