Date: Fri, 28 Dec 2012 23:00:12 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Bryan Venteicher <bryan.venteicher@gmail.com> Cc: Attilio Rao <attilio@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r244793 - in user/attilio/membarclean/dev: drm drm2 netmap virtio Message-ID: <62083874-BB5F-484C-809E-89BF404469CE@FreeBSD.org> In-Reply-To: <CAGaYwLcJ0S=AmqPZoBS_ZzwrKVJZEpmGyq0yJm5H-kW01susZQ@mail.gmail.com> References: <201212282218.qBSMIfX2015054@svn.freebsd.org> <CAGaYwLcJ0S=AmqPZoBS_ZzwrKVJZEpmGyq0yJm5H-kW01susZQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 28 Dec 2012, at 22:43, Bryan Venteicher wrote: > VirtIO uses 16-bit fields which makes it hard to adapt to MI > atomic(9). At some point, we should start deprecating atomic(9) and moving to the C11 standard versions of the same functions. These are implemented in recent clang and gcc as builtins, which provides the compiler much better optimisation opportunities, because it can reorder instructions that do not touch memory around them and can reorder any loads and stores that would not violate the happens-before relationships established by the barrier semantics (the inline asm is always a full barrier, from the perspective of the compiler, though not from the perspective of the CPU, meaning that we penalise in-order architectures). It can also ensure that sufficient padding exists. For example, an _Atomic(short) on ARM should have 2 bytes of padding so that it can be used in an ll / sc pair. The standard explicitly does not permit arbitrary casts between pointers to T and _Atomic(T) for this reason. Finally, the _Atomic qualifier can statically check that atomic and non-atomic operations are not mixed on the same type, avoiding races. David [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ3iR9AAoJEKx65DEEsqIdq2YQAMBuTPDzqFGIPWZjcPGZni2u IDk4apTcXmBphTffsHyIuTozubnJPWHTYLGzlLb9IwzRitrtWfKE17bBYECKxOry Ls+7fCg2PYa6Klhdq+mWppRlK2SXJsEJZPNHYRY/vUmr6IyqVk0vHIQPzoq8wegk yPY89DxC8TtEnUP5hpMqdKwe65/HKM3oG4jxrg/V2ZavCQrLQ6BEi7QM6Cslr47/ ZVujLiNlP7U1sSchk7QjNDlEJxERI+GRGmMr9EZKZmeOBi2EUoIxdDUqnyz87GXR /VqTjO1Z/UnwsRtfdam/WXbPfezNFO+b9A3ZQVwaZg12JNZArVAt70C0oJ3b7cjy vgCalvVhvXel7nt0oFZEqzNH37Ret4MeFO1As7mCu0T/itz98evH5yNL0m6algDa UWB1+Kv3PgFze9GnHs/EkLh/ISgkUS6Y7gTks8HgOMyfYhWndQaEYtUQ0+qTsA4b S3nqL0PFSOU/oR4Rptp7VfU00NMo+pYOp3QO3ZfWbxRPS43sSyHvomtm01S2APVs OPSA0OekB/9c5n4Ed0LD67WJrjrnIZMMZyRQI5VUjgrO6ZGbY4gYme7l6YAuQzSk +Wh5tewhveyi7Y7/qI7h+egHExhDByAJgvIC1VBoM+CbubIflZn7hKKza3qvSs/g RTSbAQD9uhlb83WnmgcH =UAqA -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62083874-BB5F-484C-809E-89BF404469CE>