Re: alignment

["Tim Prince" <tprince at computer dot org>]

I certainly didn't mean to make a blanket statement that __volatile__ is
unnecessary, and I appreciate the clarification as to when it is
necessary.  The situations where I believe that __volatile__ would
better be eliminated, provided that sufficient checking is done,  have
no unused output operands.  One of the hidden bugs which I have in mind
is the possibility of float stack overflow, which sometimes is avoided
(but not reliably so) by use of __volatile__ rather than working out the
required clobbers. That situation, of course, doesn't apply often, if at
all, in the kernel. If the kernel code has been checked thoroughly to
see that __volatile__ is required everywhere it is used, then my comment
is superfluous for that application.  However, I took the OP as a
general comment on the efficiency of gcc which was not restricted to the
kernel application, and I did not notice all the cross posts, or I would
have deleted some on my reply.

Tim Prince

"Linus Torvalds" <torvalds@transmeta.com> wrote in message
200007151735.KAA03129@penguin.transmeta.com">news:200007151735.KAA03129@penguin.transmeta.com...
> In article <006401bfee63$0d4ff4a0$0100000a@TIMYX18EWDT6RQ>,
> Tim Prince <tprince@computer.org> wrote:
> >Did you do any performance studies?  Did you enable the use of
.p2align,
> >and did that change the situation?  On the code I have worked with, I
> >saw no reason for using __volatile__ other than to hide bugs, and
that
> >may make a difference.
>
> The gcc manual explicitly states:
>
> Note that if there are only unused output operands, you will
> then also need to specify @code{volatile} for the @code{asm}
> construct, as described below.
>
> ...
>
> If the side-effects of your instruction are not purely external,
> but will affect variables in your program in ways other than
> reading the inputs and clobbering the specified registers or
> memory, you should write the @code{volatile} keyword to prevent
> future versions of GNU CC from moving the instruction around
> within a core region.
>
> ...
>
> For example, a common thing to do is to encode the "inb" instruction
on
> x86, which gcc has absolutely no way of getting at any other way than
> through the use of inline asm.
>
> The natural encoding for "inb" would be:
>
> static inline unsigned char inb(unsigned short port)
> {
> unsigned char byte;
> asm("inb":"=a" (byte):"Nd" (port));
> return byte;
> }
>
> would you not agree?
>
> However, the above is WRONG. It is wrong because:
>
>  - it can get re-ordered
>
>  - it can get deleted if the value is not actually used
>
> both of which are very very wrong, as the "inb" instruction obviously
> has tons of side effects that basically cannot be described to the
> compiler.
>
> Pray tell me how you'd fix that without the use of "volatile"?
>
> [ Yes, you _can_ fix it. You can lie. You can say that the instruction
>   changes memory, and use a "memory" clobber. That should make gcc
>   unable to re-order it or remove it, because we're saying that it
>   changes memory in ways that gcc doesn't know about. Is that really
the
>   preferred syntax? And if so, what's the point in having a
__volatile__
>   at all? Makes no sense to me: the __volatile__ thing at least is
>   conceptually understandable, a "memory" clobber would just be an
>   obvious workaround for a lack in the compiler ]
>
> In short, your statement that "volatile" is mainly to be used to hide
> bugs is nonsense, and it's obviously equally non-sensical for gcc to
> insert a ".align" directive in front of the asm.
>
> If the user is using inline assembly and really wants to align the
code,
> he can damn well do so by hand.  The compiler doing it for him is
> obviously an extremely silly thing to do that buys absolutely nothing.
>
> Linus