This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: asm issues




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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]