asm volatile

Dear all,

I was wondering what does "asm volatile" do.

Best regards

Reply to
aamer
Loading thread data ...

Nothing. It's invalid syntax:

Python 2.4.4 (#1, Oct 28 2007, 15:02:13) [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

File "", line 1 asm volatile ^ SyntaxError: invalid syntax

--
Grant Edwards                   grante             Yow! ... the MYSTERIANS are
                                  at               in here with my CORDUROY
 Click to see the full signature
Reply to
Grant Edwards

Yup, I had a similar problem:

C:\>asm volatile 'asm' is not recognized as an internal or external command, operable program or batch file.

JJS

Reply to
John Speth
Reply to
Brendan Gillatt

You're not doing it right. Darwin told me to beat it, which might give better results:

Last login: Mon Feb 4 09:49:29 on console Welcome to Darwin! F407718-MacBook:~ larwe$ asm volatile

-bash: asm: command not found

Reply to
larwe

Try the first hit on google for "asm volatile"

Reply to
Arlet

aamer schrieb:

asm volatile is gcc specific syntax (why does everyone else here makes stupid jokes about this? It's a valid question, and imho a "must know" for an embedded engineer. Shame on you!).

Anyway, it tells the compiler to not move things around, inline, loop-unroll, optimize or even remove the code. It basically tells GCC not even try to think about what the ASM code does and what the side-effects are. It tells GCC to just inline it into the code.

There are two places where you need it. First: If you write inline asm-code in gcc and don't get the constraints right (no shame - it's a horrible syntax) or 2nd: You simply don't have no visible side-effects because you talk to some kind of memory mapped IO or special registers GCC has no idea about.

Otherwise (e.g. your asm-routine is just calculating something) you do yourself a favor if you simply get your constraints right, let the compiler understand what you do, and you may get a little performance/code-size boost.

Nils

Reply to
Nils

In message , Nils writes

Then ask on a gcc NG

Only for gcc. As pointed out it is certainly not even vaguely sensible C

ABSOLUTELY NOT. I have been doing embedded for 30 years and never seen it.

I assume you know all the non standard extensions in all the embedded compilers?

That's a silly thing to do any way.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

The jokes were rather stupid, but the point we were making was important. Perhaps we were a bit too subtle. Here's the long winded version:

formatting link

formatting link

We were trying to teach the man how to fish.

--
Grant Edwards                   grante             Yow! Uh-oh!!  I'm having
                                  at               TOO MUCH FUN!!
 Click to see the full signature
Reply to
Grant Edwards

Whatever the instructions for your compiler say.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

That's refreshing.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

People made stupid jokes because the OP made a stupid post. He provided no context whatsoever (although many experienced embedded developers would immediately see that he was using gcc), and had totally failed to make the slightest attempt at searching for an answer. If he had been asking, say, what the difference between "asm volatile" and non-volatile "asm" was, then it would be a better question.

"volatile" is not nearly as concrete as you (and many others) often think. In particular, if the compiler can figure out that a particular section of code will never be executed, then any "volatiles" ("asm volatiles" or normal volatile variable access) in that section will be removed. The code can also happily be optimized, inlined, unrolled, or anything else - but there are some restrictions, just like for other volatiles. You know that the asm volatile code will be generated and executed exactly as many times as your source code specifies, but that's about it. The compiler can happily shuffle code back and forth around the "asm volatile", and is not required to synchronise memory accesses before or after it (that's what the "memory" clobber is for).

In other words, you use it in the same sort of way as "volatile" variables.

Note that if your asm statement has no output constraints, it is effectively "volatile" automatically (if you are not producing an output, then you must be doing something the compiler doesn't understand

- otherwise, what's the point?).

Good advice.

Reply to
David Brown

gcc is used for embedded development, and inline assembly (volatile or not) is more relevant to embedded programmers than most non-embedded programmers, so this newsgroup is entirely appropriate.

Most (all?) embedded C compilers support inline assembly, and many have some way of indicating a particularly "volatile" assembly passage. The syntax will vary, but the principle is the same.

Are you telling us that all the embedded compilers you have used are so much behind gcc in this area that they have no way to distinguish between "volatile" inline assembly passages and "optimisable" assembly passages that can, for example, be shuffled in and out of loops by the compiler? I know that, for example, Diab Data's compilers can do marvellous things with inlined assembly, and have a syntax to allow it.

Most experienced embedded developers can make a fair guess at common ones. I've never used a embedded compiler with a "__flash" non-standard keyword - but I'm confident I'd guess it's purpose. No one would expect a non-gcc user (and very few gcc users!) to understand the full gcc "asm" syntax, but if you claim you don't know what "asm volatile" means, you are simply being obtuse.

Ah well, silly me. And silly compiler writers (a great many of them) that wasted all that time and effort adding features to allow silly programmers to write silly inline assembly code.

Reply to
David Brown

On Mon, 04 Feb 2008 21:39:09 +0100, Nils wrote in comp.arch.embedded:

[snip]

Why does the OP think he has what it takes to become an embedded engineer if he is incapable of checking his tool documentation, trying a web search, or at least putting together an intelligent question?

For 99% of all embedded tool sets it does absolutely nothing. I tried adding "asm volatile" to eggs I was scrambling and I ruined them.

Some of use became embedded programmers before there was such a thing as an Internet or a comp.arch.embedded. We read manuals. And we did have access to someone who might know more about a particular topic than we did, we managed to compose a coherent, intelligent question.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

I think it all comes down to laziness rather than intelligence. I have a friend who is supposedly as qualified as I am in the field of computing, but insists on regularly picking up the phone and making a long distance call to ask me a question that he thinks I can answer. 95% of the time I use google to "sanity-check" my response, and it's always in the 1st or

2nd hit on the first page.... I've given up telling him this :(

You need to sear them quickly on high heat first! ;)

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

On Tue, 05 Feb 2008 14:49:37 +1100, Mark McDougall wrote in comp.arch.embedded:

Agreed, and please note that I specifically did not cast any aspersions on the OP's intelligence. The phrase "what it takes" certainly includes some minimum intelligence, but far more includes attributes like initiative and resourcefulness.

I'll give it another try, will you make the toast?

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

Yes.

No.

No generally far more advanced.

Words fail me.

Yes.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

Then let me try to help.

Suppose your processor has support for instructions that have no direct equivalent in C - rotations, DSP-type instructions, etc., and you want your code to be as small and fast as possible. For example, you might define an assembly function or macro "satadd(a, b)" which does a saturated addition of two numbers. With optimisable inline assembly, the compiler would know that this is a "const" or "pure" function - one whose results depend entirely on its inputs, and has no side effects. Thus the compiler is able to move calls to this function/macro around, such as pulling constant calls outside of loops or branched code, and avoiding executing the code more than strictly necessary. The compiler is also able to provide the assembly code with registers that it may use

- that way, there is no need to save or restore registers unnecessarily around the assembly code.

So any compiler that is able to handle inlined assembly at least as well as gcc must have some way to distinguish between assembly sections that

*can* be optimised and moved around in this way, and those that cannot (unless it directly analyses the effects of the assembly code, which is pretty unlikely).

I don't have detailed information on more than a couple of high-end commercial compilers on hand, and neither of them support optimisable asm statements. Thus all their "asm" statements and expressions are, in gcc terms, "asm volatile". The manuals stressed that inlined assembly would block the optimiser, and that you probably want to compile such code without optimisation at all. In other words, their support for inline assembly is not nearly up to the levels of gcc. On the other hand, they did have more pre-defined intrinsic functions which can avoid the need for inline assembly in some cases.

Reply to
David Brown

writes

writes

stupid jokes about this?

passage. The syntax will vary, but the

behind gcc

assembly passages and "optimisable"

equivalent in C - rotations, DSP-type

possible. For example, you might define an

two numbers. With optimisable inline

one whose results depend entirely on its

An intrinsic would be better for this particular example.

pulling constant calls outside of loops

necessary. The compiler is also able to provide

to save or restore registers

gcc must have some way to distinguish

way, and those that cannot (unless it

Actually analysing the effect of the assembly code is the only correct way of dealing with inline assembler. No other approach can be called "optimizable inline assembler". Basically inline assembler and compiler optimization are mutually exclusive things - unless the compiler understands the effects, constraints, timing, size of each instruction. Most inline assembler syntax, including GCC, is not about optimization of inline assembler but an effort to reduce the negative effect of inline assembler on the rest of the code.

I designed an inline assembler which is 100% optimizable and seamlessly integrates with C/C++ (each operand can be a C expression). This means each inline assembler instruction is treated like any other instruction and subject to exactly the same set of optimizations. All this happens automatically without needing any arcane syntax.

Eventhough it is more than 10 years old now, it is still the most advanced inline assembler you'll ever see. It upset quite a lot of people as the compiler was able to optimise inline assembler instructions when they expected it to behave like a real assembler.

compilers on hand, and neither of them

expressions are, in gcc terms, "asm

optimiser, and that you probably want to

for inline assembly is not nearly up to

intrinsic functions which can avoid the need for

All inline assembler that isn't analysed by the compiler is by definition "asm volatile". It has a negative effect on the rest of the code as the compiler never knows exactly what it does (eg. changing the stack pointer!).

wasted all that time and effort adding

Chris has a point here: many uses of inline assembler are unnecessary. Intrinsics are a far better way of using additional instructions, and when you do need to squeeze the last few percent of performance, it's best to avoid the complexity and drawbacks of inline assembler and use a real assembler.

Wilco

Reply to
Wilco Dijkstra

Where appropriate and available, intrinsics are often better (this was merely a simple hypothetical example) - although they are normally restricted to single assembly instructions while your asm function/macro may cover more. Even better, of course, is when the compiler can recognise patterns in the C source and generate code directly (examples would be good optimisation of dsp-style code).

The term "optimise" is an abuse in itself - the compiler does its best to produce better code, but you've no guarantees of truly "optimal" code. But it's fair enough to describe the inline assembly features as reducing the negative consequences of the asm statements, rather than optimising them as such - the asm code itself is not changed by the compiler (except the registers used, and possibly addressing modes, may change). The point of getting the gcc asm syntax accurate is to allow the optimiser to generate the best possible assembly for the C code around the inline asm code, as well as to be able to move or remove the asm statements when possible.

It's certainly possible to do this (obviously, since you've done it!). If nothing else, many assembly instructions can be directly translated into C (with registers replaced by local variables), and the C optimiser will do a reasonable job. Of course, there is normally little point in doing this - if the code can be written in C in the first place, you don't want to use inline assembler. The use of inline assembly is mainly for constructs or instructions that don't translate well into C.

I'd imagine messing with the assembly would upset some people - I've regularly met people on mailing lists who insist on turning off optimisation on their compiler because they don't like the compiler being "smart", and believe that the compiler should (and will) do exactly as they say. When people get like that about their C code, they'll be a lot worse about their assembly!

The compiler *does* know a fair amount about the assembly - based on what you tell it (with gcc asm constraints). In particular, it *does* know if you are changing memory, or registers, and it knows if you are causing other side effects. For example, it knows when your code has no side effects (when your asm statement is not "volatile", and it has an output). It also knows that you are not changing the stack pointer (except temporarily), or other registers - because you'd include them in the clobber list if you were. There are other things it does not know, such as the size or timing of the assembly section, and there are limits to the descriptions (you either clobber all memory, or no memory - you can't tell the complier you're only clobbering some of it).

As I said above, intrinsics are often a better choice - when they are available, and when they are appropriate. However, inline assembly in gcc allows you to express things reliably and completely (though the syntax can be a bit daunting), and means that low-level code can often be expressed by a source or header level inline assembly definition, rather than a compiler level intrinsic. For example, on the ColdFire, there are a number of special registers that are used for low-level setup such as setting the base address of the internal RAM, or cache control. These registers must be accessed by special assembly codes. On gcc, this is done easily with inline assembly, while on other compilers it is perhaps done with specific intrinsics for each special register. When a new ColdFire comes out, with a different internal address for the same named special register, the intrinsic-based compiler must be modified to support the new core - while using inline assembly, it is the program's source code that changes. From experience of exactly this situation, I know which system I find better - buy an update to the commercial compiler, or modify a single line of source code?

Overly using inline assembly, especially in the name of "optimisation", is silly, of course. But appropriate use is a good thing - it can mean that traditional assembly code such as C startup routines can be written in C with a couple of lines of inline assembly, rather than pure assembly.

Reply to
David Brown

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.