Thread (121 messages) 121 messages, 13 authors, 2021-09-24

Re: [RFC] LKMM: Add volatile_if()

From: Segher Boessenkool <hidden>
Date: 2021-06-04 19:57:23
Also in: linux-arch, lkml

On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:
On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
quoted
My point is that you ask compiler developers to paint themselves into a
corner if you ask them to change such fundamental C syntax.
Once we have some experience with a language extension, the official
syntax for a standardized version of that extension can be bikeshedded.
Committees being what they are, what we use in the meantime will
definitely not be what is chosen, so there is not a whole lot of point
in worrying about the exact syntax in the meantime.  ;-)
I am only saying that it is unlikely any compiler that is used in
production will want to experiment with "volatile if".
quoted
I would love to see something that meshes well with the rest of C.  But
there is no 1-1 translation from C code to machine code (not in either
direction), so anything that more or less depends on that will always
be awkward.  If you can actually express the dependency in your source
code that will get us 95% to where we want to be.
^^^
quoted
quoted
Data dependencies, control dependencies and address dependencies, C
doesn't really like them, we rely on them. It would be awesome if we can
fix this.
Yes.  The problem is that C is a high-level language.  All C semantics
are expressed on a an "as-if" level, never as "do this, then that" --
well, of course that *is* what it says, it's an imperative language just
like most, but that is just how you *think* about things on a conceptual
level, there is nothing that says the machine code has to do the same
thing in the same order as you wrote!
Which is exactly why these conversations are often difficult.  There is
a tension between pushing the as-if rule as far as possible within the
compiler on the one hand and allowing developers to write code that does
what is needed on the other.  ;-)
There is a tension between what users expect from the compiler and what
actually is promised.  The compiler is not pushing the as-if rule any
further than it always has: it just becomes better at optimising over
time.  The as-if rule is and always has been absolute.

What is needed to get any progress is for user expectations to be
feasible and not contradict existing requirements.  See "^^^" above.


Segher
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help