Subj : Re: Memory visibility and the C compiler... ( a bit long )
To   : comp.programming.threads
From : SenderX
Date : Thu Jan 13 2005 08:40 am

> Not everything.

:O

First of all, thanks for responding.


> Reordering across "critical instructions" (inline asm
> and/or external asm functions) is still possible (and is in fact
> desirable as long as it doesn't break anything).

Are you talking about how the C compiler can reorder calls to external
assembled functions? Or, how local variables might be moved in adverse
ways in the presence of multiple unrelated external function calls? I was
assuming that nasm,
masm, gas, ect... would not reorder the "critical instructions" wrt the
assembly routine itself. I think I might be getting what your hinting at: C
can still
screw you...


> You presume to have
> either stupid optimizers (no IPA and/or full-stop barrier for the
> assembly stuff) or really smart ones capable to understand reordering
> constraints embedded in the asm stuff.

I would greatly disapprove of a C compiler inspecting the instructions of
my externally assembles routines! Is that anywhere near what you are getting
at?

;(...


> > 2.2 Memory Barriers ...
>
> Your notation for unidirectional constraints sucks.

Good thing this is a rough-draft!   :)


> And get rid of
> volatiles. Stick to C++ and atomic<> with member function overloads
> on msync type labels/tags to express reordering constraints. E.g,

Yeah, that's a lot more elegant than macros, however I need to use C...

:|

.