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
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
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.
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
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
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.
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.