This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: asm issues
- To: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Subject: Re: asm issues
- From: Linus Torvalds <torvalds at transmeta dot com>
- Date: Fri, 7 May 1999 14:49:04 -0700 (PDT)
- cc: submit-linux-egcs at transmeta dot com
On Fri, 7 May 1999, Joern Rennecke wrote:
> > Would it not make sense to say that we're really passing the asm just
> > the _address_ of a "m" argument? After all, that's really what the code
> > generated does: if you do
> >
> > asm("lea %1,%0":"=r" (reg):"m" (memory));
>
> We already have the 'p' constraint letter specifically for load
> address instructions.
But that doesn't imply changing or reading what it points to, and as such
is often not very useful.
Maybe I shouldn't have used "lea" as the example: the example was meant to
show that even though you _think_ you give the asm a memory argument,
that's not really what you do. You give it a pointer - like it or not.
Whether you call it a pointer or not is irrelevant. Just live with the
fact that "m" does indeed imply a pointer implementation-wise. I'm just
suggesting that gcc simply own up to that fact, and consider "m" to be
equivalent to passing in a pointer to any other "black box" (ie function).
> > problem: it becomes very obvious what gcc has to do, because you
> > suddenly don't even know whether maybe the function (read "asm") might
> > save away the pointer for later use etc..
>
> Then the object being references must be declared as volatile.
What?
Just because I pass in a pointer to an external function does _NOT_ mean
that I have to declare it volatile in any C implementation I have ever
used. In fact, that would be against standard C.
Think of an inline asm as a function that the compiler doesn't know what
it really does. Which, btw, it really is, no? And think of "m" as passing
in a pointer to that function.
(Think of "p" as passing in a pointer too, but with the additional
guarantee that it is only ever used as a value, kind of like "%p" in the C
printf setup - it's a pointer that is not necessarily even dereferenced).
> "m" doesn't mean pass by reference - only that the operand is passed in
> memory.
The whole point of my email was to make people maybe drop pre-conceived
notions. I seem to have failed.
Linus