[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: New problems with gcc-2.8.0 based code - NOW FIXED!
From:       Paul Koning <pkoning () xedia ! com>
Date:       1997-12-30 21:17:01
[Download RAW message or body]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

 Paul> You mentioned the issue of an asm with inputs only that
 Paul> should still be treated as non-volatile.  I have a hard time
 Paul> conceiving of such a beast.  Can you show a real world
 Paul> example?

 Richard> Lighting some light. In such cases, you don't care whether
 Richard> or not it was moved around a few statements in the basic
 Richard> block.  Indeed, I'd say that *most* occurrences of asm would
 Richard> be in this category.

Hm.  I suppose that's possible, IF you're just trying to turn it on.
It doesn't work if you want it to blink, because the compiler can move
the on/off asm statement right around your blink delay unless you use
the volatile rule.

As for "most occurrences", I beg to differ.  I can't think of any
outputless asm statement I've ever written or seen anywhere that IS in
the "movable" category.  The example you gave is the first I've seen
that comes even close.

And in that example it would be perfectly harmless to use the rule as
documented (i.e., the asm is volatile).  Is there any example of an
input-only asm statement that *should not* be treated as volatile,
i.e., it actually hurts to make it non-movable automatically?  If such
a thing realistically exists it might make sense to invent a
"novolatile" keyword; without meaningful examples, the right answer is
to do what's documented.

Considering Joe Buck's analogy: would you consider it acceptable for a
compiler to permute the order of void function invocations unless
explicitly instructed not to do so?  I don't think so.  An asm
statement is also a function invocation, it just has a somewhat
different syntax.

	paul

[prev in list] [next in list] [prev in thread] [next in thread]