On Saturday, November 13, 2021 at 9:24:09 PM UTC+2, MitchAlsup wrote:
> On Saturday, November 13, 2021 at 12:38:24 PM UTC-6, Niklas Holsti wrote:
> > (I'm keeping a lot of the context because it has been quite a while
> > since the discussion that Tim resumed.)
> > On 2021-11-13 17:56, Tim Rentsch wrote:
> > > Niklas Holsti <niklas...@tidorum.invalid> writes:
> > >
> > >> On 2021-10-27 4:28, Tim Rentsch wrote:
> > >>
> > >>> Niklas Holsti <niklas...@tidorum.invalid> writes:
> > >>>
> > >>>>> [.. volatile ..]
> > >>>>
> > >>>> These discussions of volatile, and execution order wrt timing,
> > >>>> gave me an idea: perhaps C (and other languages) should allow
> > >>>> marking functions (subprograms) as "volatile", with the meaning
> > >>>> that all of the effects of a call of that function (including use
> > >>>> of processor time) should be ordered as volatile accesses are
> > >>>> ordered, with respect to other volatile accesses.
> > >>>>
> > >>>> For example, if x and y are volatile variables, and foo is a
> > >>>> volatile function, then in this code
> > >>>>
> > >>>> x = 1;
> > >>>> foo ();
> > >>>> y = 1;
> > >>>>
> > >>>> we would be sure that all effects and all dynamic resource usage
> > >>>> of the foo() call would occur between the assignments to x and to
> > >>>> y.
> > >>>>
> > >>>> A more flexible approach would be to mark selected function calls
> > >>>> as volatile, in the same way that C allows in-line use of
> > >>>> pointer-to-volatile to force a volatile access to an object that
> > >>>> is not itself marked volatile. Something like:
> > >>>>
> > >>>> x = 1;
> > >>>> (volatile) foo ();
> > >>>> y = 1;
> > >>>>
> > >>>> Are volatile functions and/or volatile function calls a good idea?
> > >>>
> > >>> Let me propose a simpler mechanism that I believe does a better
> > >>> job of what (I think) it is you want to do. By way of example:
> > >>>
> > >>> * (_Volatile int *) &x = 1;
> > >>> foo();
> > >>> * (_Volatile int *) &y = 1;
> > >>>
> > >>> The semantics of the new _Volatile qualifier, speaking
> > >>> informally, is that it imposes a sequence point in the actual
> > >>> machine, not just in the abstract machine. So all logically
> > >>> previous evaluations must be finished before a volatile access,
> > >>> and after a volatile access all logically subsequent evaluations
> > >>> must not yet be started. To say that another way, no expression
> > >>> evaluation (including side effects) may be "moved across" a
> > >>> read or write to a _Volatile object.
> > >>>
> > >>> Note that foo() is a call to an ordinary function, and expressions
> > >>> in foo() may be re-ordered in all the usual ways, except that they
> > >>> must not be "moved across" the assignment to x or the assignment
> > >>> to y.
> > >>
> > >> That is exactly the semantics I intended, as I described in my
> > >> response to David Brown. So we are creating the same functionality
> > >> but using different source-code mechanisms - my suggestion marks the
> > >> call (or the function), and interacts with the existing "volatile"
> > >> mechanism, while your suggestion defines a new and stronger
> > >> "_Volatile" access.
> > >
> > > Part of what motivated my proposal is I think _Volatile is useful
> > > all by itself. When people use volatile, I think in many cases
> > > what they expect, and also what is actually needed, is something
> > > closer to _Volatile than it is to volatile. If indeed _Volatile
> > > is useful in its own right, then adding _Volatile to the language
> > > gets both benefits, so that seems like a win.
> > >
> > >> I suppose only compiler implementors can tell us which of the
> > >> two is easier to implement.
> > >
> > > I've been doing some thinking on this question, and I'm pretty
> > > sure that what it take to implement them is basically the same
> > > for the two approaches.
> > >
> > >> Your suggestion has the benefit that the "immovable" code is not
> > >> necessarily a function call, as in my proposal. However, I had in
> > >> mind an extension to let any code block be defined as immovable in
> > >> this sense, perhaps as
> > >>
> > >> (volatile) { some code ... };
> > >>
> > >> which would let the programmer use a local encapsulation of the
> > >> immovable code, without defining a function just for that purpose.
> > >
> > > I can't help feeling that introducing a special form just for
> > > this purpose is a red flag that we are going down a bad path.
> > Well, blocks { ... } exist already, and if the preceding suggestion of
> > "(volatile) foo()" is implemented, the block form does not seem to be
> > much of an extension.
> <
> My question is:: in a (volatile) { block } does EVERY memory access
> take on the volatile moniker ? does the { block } take on the moniker
> and if so exactly what does that mean ? is no memory reordering
> allowed whatsoever ?
> <
> {I am pretty sure I have no idea as to what (volatile) foo(); means;
> especially if foo() has already been compiled and placed in a library.
> Do you reach into the library and then attach volatile to every access?
> But perhaps one simply means that one cannot put a volatile in a
> location other than its resting memory location while the foo() is
> active? !?!}
> <
> > > But let me ask a question. I'm not sure what problem motivated
> > > your original suggestion. What problem is it that you want to
> > > solve, where having some mechanism like the ones we have been
> > > discussing would help solve it?
> <
> > My suggestion was a response to some posts about controlling
> > (minimizing) the time elapsed between two volatile accesses. Something
> > like the following, where x and y are volatile, but z and q not:
> >
> > z = (some long computation);
> > q = x;
> > y = z + q;
> >
> > The problem was that some compiler moved the long computation after the
> > reading of x, thus greatly increasing the delay between the reading of x
> > and the assignment to y. That code movement is of course now allowed,
> > because the computation is not "volatile", nor is the assignment to z.
> <
> Volatile was invented for those variables (like memory mapped I/O registers)
> that have to be read/written exactly the same number of times they are mentioned
> in the source code. These kinds of memory locations change their values upon
> being read, and do not necessarily have the last value written.
> <
> Now, it looks like you are suggesting that volatile has assumed another purpose:
> that of scheduling access to potentially shared variables in shared memory.
> <
> But in any event:: why was the code NOT written::
> z = (some long computation);
> y = z + x;
> <
> Or even:
> y = (some long calculation) + x;
> <
> The assignment of x into q, it seems to me, indicates the programmer wanted to
> separate the volatile access from the calculation. And thus, the compiler should
> have the mentioned freedom!

Here are relevant messages
https://groups.google.com/g/comp.arch/c/HMgFkk6BBqE/m/ncfgGNyIAgAJ
https://groups.google.com/g/comp.arch/c/HMgFkk6BBqE/m/z72ie5SYAgAJ
https://groups.google.com/g/comp.arch/c/HMgFkk6BBqE/m/glqoZoqaAgAJ
https://groups.google.com/g/comp.arch/c/HMgFkk6BBqE/m/SweM0XzHAgAJ

> <
> >
> > A work-around for the above example would be to make z volatile too, but
> > that is not as direct as saying that the computation shall not be moved
> > past volatile accesses.
> <
> Making z volatile requires its assigned location be memory and not be allocated
> to a register. A register retains the value that was last written and returns same
> upon being read; and thus has none of the properties one wants to coin to cause
> the volatile moniker to be attached.
> <
> Not sure you want to go that far.
> <
> > > Tangential note re: comments by David Brown. For several years
> > > now I've been following a policy of not reading postings from
> > > David Brown. Back when I was reading them I found his comments
> > > were mostly thoughtless and arrogant.
> > I don't find them so. David does usually give his opinions strongly and
> > without softening, but they are usually valid opinions (meaning that I
> > mostly agree with them).