On 14-11-2012 21:15, Sean Kelly wrote:
On Nov 14, 2012, at 12:07 PM, Alex Rønne Petersen <[email protected]> wrote:
On 14-11-2012 21:00, Sean Kelly wrote:
On Nov 14, 2012, at 6:16 AM, Andrei Alexandrescu
<[email protected]> wrote:
On 11/14/12 1:20 AM, Walter Bright wrote:
On 11/13/2012 11:37 PM, Jacob Carlborg wrote:
If the compiler should/does not add memory barriers, then is there a
reason for
having it built into the language? Can a library solution be enough?
Memory barriers can certainly be added using library functions.
The compiler must understand the semantics of barriers such as e.g. it doesn't
hoist code above an acquire barrier or below a release barrier.
That was the point of the now deprecated "volatile" statement. I still don't
entirely understand why it was deprecated.
The volatile statement was too general. All relevant compiler back ends today
only know of two kinds of volatile operations: Loads and stores. Volatile
statements couldn't ever be properly implemented in GDC and LDC for example.
Well, the semantics of volatile are that there's an acquire barrier before the
statement block and a release barrier after the statement block. Or for a
first cut just insert a full barrier at the beginning and end of the block.
Either way, it should be pretty simply for a compiler to handle if the compiler
supports mutex use.
I do like the idea of built-in load and store intrinsics only because D only
supports x86 assembler right now. But really, it would be just as easy to fan
out a D template function to a bunch of C functions implemented in separate ASM
code files. Druntime actually had this for core.atomic on PPC until not too
long ago.
Well, there's not much point in that when all compilers have intrinsics
anyway (e.g. GDC has __sync_* and __atomic_* and LDC has some intrinsics
in ldc.intrinsics that map to certain LLVM instructions).
--
Alex Rønne Petersen
[email protected]
http://lycus.org
